On Sep 20, 2014, at 7:41 AM, Martin <m_btrfs@xxxxxxxxx> wrote: > -----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: [snip] > On a comparatively super dual core Athlon64 SSD btrfs three disk btrfs > raid1 system: [snip] Yeah between XFS and Btrfs in the same VM I'm not seeing anything like Marc's numbers. Both fs's are newish but have been significantly updated, and the Btrfs one has a pile of debuginfo rpms installed. XFS: time mount /mnt/xfs time ls -l /mnt/xfs/usr/bin real 0m0.205s ls -l /mnt/xfs/usr/bin | wc 1625 14978 100833 Btrfs: time mount /mnt/btrfs time ls -l /mnt/btrfs/usr/bin real 0m0.482s ls -l /mnt/btrfs/usr/bin | wc 1817 16724 110364 XFS: time tree -al /mnt/xfs/usr 14050 dirs, 193464 files real 18.336 Btrfs: time tree -al /mnt/btrfs/usr 15552 dirs, 165958 files real 21.029s > (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!) This is kinda interesting. 20 lines of code. http://blog.delphix.com/uday/2013/02/19/78/ I'm curious what pathologies it'd reveal in Btrfs, but also say XFS on LVM thinp with and without snapshots. Chris Murphy -- 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
