Hi, just my two cents here.^_^
> 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 I did a quick benchmark for this: Testing tool is something like follows, it create 50W files and 50w directories under a fresh mkfs filesystem, btrfs is just a little slower than ext4: For ext4: real 0m9.295s user 0m2.252s sys 0m7.010s For btrfs: real 0m10.207s user 0m1.347s sys 0m8.353s And test is done with a 20G vm disk(backend is hard disk) with latest kernel compiled under VM. #!/bin/bash umount /dev/sdc #~/source/e2fsprogs/misc/mke2fs -F -O inline_data /dev/sdc >/dev/null mkfs.ext4 -F /dev/sdc >/dev/null mount /dev/sdc /mnt ./mdtest -d /mnt/ext4 -n 500000 -C >&/dev/null echo 3 > /proc/sys/vm/drop_caches time ls -l /mnt/ext4/\#test-dir.0/mdtest_tree.0 >& /dev/null umount /dev/sdc mkfs.btrfs -f /dev/sdc >/dev/null mount /dev/sdc /mnt ./mdtest -d /mnt/btrfs -n 500000 -C >/dev/null echo 3 > /proc/sys/vm/drop_caches time ls -l /mnt/btrfs/\#test-dir.0/mdtest_tree.0 >& /dev/null So here i think Btrfs is not that you think much slower than Ext4 at least for ‘ls’ which means directory reading performances… Here i think you could do several ways to improve or avoid such things: 1. create a separate subvolume or separate partition for /usr and use noatime mount option if possible.(I remembered Marc MARLIEN gave some good example for this) 2. running defrag command to reduce fragmentation. Reasons for doing these are because that directory like /usr/bin is regularly accessed which will also trigger Btrfs widely COWed which may cause serious fragmentation and that may cause some bad performances.. And another factor btrfs in default all files are mixed together in a a fs B-tree, which means that all read/write lock will walk through same tree which may cause some lock contention problem. So use a separate subvoulme tree could improve lock thing a bit for that IMO. BTW, next time if someone reported some problems,it will be nice to give your detailed information for example kernel version, how many subvolumes/snapshots, btrfs file system configurations, usage(running btrfs file show,btrfs file df e.g.) these informations are useful for others to reproduce and analysis... > > also mounting large partitons (several 100Gs) takes lot of time on btrfs. > Better to defer it during boot using e.g. "noauto,x-systemd.automount". > > Marc Best Regards, Wang Shilong -- 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
