On Mon, Jun 4, 2012 at 8:50 PM, Alexander E. Patrakov
wrote:
> 2012/6/5 Kok, Auke-jan H wrote on systemd-devel
> list:
>> It seems your system is taking well into 15+ seconds before btrfs is
>> actually *ready* on your system, which seems to be the main hiccup
>> (note, speculation here). I've personally become a bit displeased with
>> btrfs performance recently myself, so, I'm wondering if you should try
>> ext4 for now.
>>
>> Other than that, after btrfs/udev finally pops to life, things seem to
>> start relatively quickly.
>
> I think btrfs is to blame here, because I think my system started to
> be affected by this problem after ext4 -> btrfs conversion.
>
> I recently changed my ext4-on-lvm gentoo system at home by
> defragmenting the LVM (http://bisqwit.iki.fi/source/lvm2defrag.html),
> converting the biggest (200 GB, 80% used, mostly video files, git
> trees and SVN checkouts of various projects) logical volume to btrfs,
> making the backup of metadata, deleting the LVM partition and creating
> ordinary partitions in places that were occupied by LVM volumes before
> according to the backup. It worked. Then I made a btrfs subvolume and
> transferred the contents of the former root partition there using tar.
> So now I have two copies of my root filesystem - one on ext4 and one
> on btrfs. I recreated an initramfs for each of them using dracut.
> Result: boot from ext4 takes less than 15 seconds, while boot from
> btrfs takes 9 minutes (or 5 minutes if I disable readahead - the data
> file is not valid anyway on btrfs).
>
> One problem is btrfsck in the dracut-created initramfs - it fires
> every time (with btrfs mounted read-only?). The other problem is the
> btrfs-cache-1 kernel thread - I was told on #btrfs that it is a
> one-time thing, but apparently it wants to do its caching every boot
> due to some breakage. During the boot, there are also warnings about
> hung tasks with some locks held.
>
> I am attaching a dmesg file illustrating all of the problems mentioned above.
I've had the same (bad) experiences since 3.3.
The "one time thing" is creating the free space cache. On my home
systems, with 3.4.x, it's still creating them *every* boot, which
certainly accounts for IO busy, which on a sluggish spinning rust is
disastrous, to say the least.
Hung tasks in btrfs have been present since it was merged. Remember
that they're only a warning - eventially almost always they will
unhang. But still ver frustrating.
I'm currently dropping btrfs from my home development system because
I've spent too much time in the last month trying to get my btrfs
volumes back up after a kernel upgrade. So, I feel your pain.
Auke
>
> --
> Alexander E. Patrakov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
