-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/09/14 09:23, Marc Dietrich wrote: > Am Freitag, 19. September 2014, 13:51:22 schrieb Holger > Hoffstätte: >> >> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote: >> >>> I have a particularly uncomplicated setup (a desktop PC with a >>> hard disk) and I'm seeing particularly slow performance from >>> btrfs. A `git status` in the linux source tree takes about 46 >>> seconds after dropping caches, whereas on other machines using >>> ext4 this takes about 13s. My mail client (evolution) also >>> seems to perform particularly poorly on this setup, and my >>> hunch is that it's spending a lot of time waiting on the >>> filesystem. >> >> This is - unfortunately - a particular btrfs >> oddity/characteristic/flaw, whatever you want to call it. git >> relies a lot on fast stat() calls, and those seem to be >> particularly slow with btrfs esp. on rotational media. I have the >> same problem with rsync on a freshly mounted volume; it gets fast >> (quite so!) after the first run. > > my favorite benchmark is "ls -l /usr/bin": > > ext4: 0.934s btrfs: 21.814s So... On my old low power slow Atom SSD ext4 system: time ls -l /usr/bin real 0m0.369s user 0m0.048s sys 0m0.128s Repeated: real 0m0.107s user 0m0.040s sys 0m0.044s and that is for: # ls -l /usr/bin | wc 1384 13135 88972 On a comparatively super dual core Athlon64 SSD btrfs three disk btrfs raid1 system: real 0m0.103s user 0m0.004s sys 0m0.040s Repeated: real 0m0.027s user 0m0.008s sys 0m0.012s For: # ls -l /usr/bin | wc 1449 13534 89024 And on an identical comparatively super dual core Athlon64 HDD 'spinning rust' btrfs two disk btrfs raid1 system: real 0m0.101s user 0m0.008s sys 0m0.020s Repeated: real 0m0.020s user 0m0.004s sys 0m0.012s For: # ls -l /usr/bin | wc 1161 10994 79350 So, no untoward concerns there. Marc: You on something really ancient and hopelessly fragmented into oblivion? > also mounting large partitons (several 100Gs) takes lot of time on > btrfs. I've noticed that also for some 16TB btrfs raid1 mounts, btrfs is not as fast as mounting ext4 but then again all very much faster than mounting ext4 when a fsck count is tripped!... So, nothing untoward there. For my usage, controlling fragmentation and having some automatic mechanism to deal with pathological fragmentation with such as sqlite files are greater concerns! (Yes, there is the manual fix of NOCOW... I also put such horrors into tmpfs and snapshot that... All well and good but all unnecessary admin tasks!) Regards, Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlQdhBwACgkQ+sI3Ds7h07f/VwCgkHPjrIkBkWh5zrKwvN7fXalZ LWcAoIbLFEoc7iTNLzgSChNvnYatIkuZ =YlDI -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
