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. 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 -- 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
