On 2014-09-19 09:51, Holger Hoffstätte wrote:
I find that kind of funny, because regardless of filesystem, stat() is one of the *slowest* syscalls on almost every *nix system in existence.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.
While I don't know for certain, I think it's largely just a side effect of the lack of performance tuning in the BTRFS code.The simplest thing to fix this is a "du -s >/dev/null" to pre-cache all file inodes. I'd also love a technical explanation why this happens and how it could be fixed. Maybe it's just a consequence of how the metadata tree(s) are laid out on disk.
I've tried mounting with noatime, and this has had no effect. Anyone got any ideas?Don't drop the caches :-) -h
smime.p7s
Description: S/MIME Cryptographic Signature
