Btrfs devel - Jun 2012 - Re: [systemd-devel] systemd-udevd: excessive I/O usage

2012/6/5 Kok, Auke-jan H <auke-jan.h.kok@intel.com> 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.

-- 
Alexander E. Patrakov

On Martes, 5 de junio de 2012 09:50:56 Alexander E. Patrakov
escribió:
> 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).
I also had this problem. It turns out that btrfs was creating the 
space cache from scratch (which takes several minutes) on each boot,
for some reason. I added the space_cache mount option to fstab,
and now my system boots fast. I suggest trying it.

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[resend, for some reason kmail formatted the previous message with html]

On Martes, 5 de junio de 2012 09:50:56 Alexander E. Patrakov
escribió:
> 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).
I also had this problem. It turns out that btrfs was creating the 
space cache from scratch (which takes several minutes) on each boot,
for some reason. I added the space_cache mount option to fstab,
and now my system boots fast. I suggest trying it.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

2012/6/5 Diego Calleja <diegocg@gmail.com>:
> [resend, for some reason kmail formatted the previous message with html]
>
> On Martes, 5 de junio de 2012 09:50:56 Alexander E. Patrakov escribió:
>> 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).
>
> I also had this problem. It turns out that btrfs was creating the
> space cache from scratch (which takes several minutes) on each boot,
> for some reason. I added the space_cache mount option to fstab,
> and now my system boots fast. I suggest trying it.
It helped me, too - but ext4 is still faster under the typical
"startup under systemd" load type. The difference manifests itself as
GDM login screen sometimes timing out some components of its fancy
version (due to something resembling kernel bug 12309) and falling
back to the simple non-gnome-shell version.

Sorry for hijacking the thread, but the amount of parallelization
achieved by systemd is way too much for a rotating drive from 2007,
especially since some system components like gdm have aggressive
timeouts easily triggered by disk i/o.

-- 
Alexander E. Patrakov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, Jun 4, 2012 at 8:50 PM, Alexander E. Patrakov
<patrakov@gmail.com> wrote:
> 2012/6/5 Kok, Auke-jan H <auke-jan.h.kok@intel.com> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html