3 ms·
Two things are slow. One is random rewriting of large file contents like a database does. It isn't that bad, but you wouldn't want to run something like Mongo
by rogerbinns 14y ago
Two things are slow. One is random rewriting of large file contents like a database does. It isn't that bad, but you wouldn't want to run something like MongoDB on btrfs, although I did so for a while. You may see similar issues with virtualization disk images, although that will depend on how much writing you do. I still do this, but don't do much writing and performance is acceptable.
The other part is fsync calls. Doing a package install on Debian/Ubuntu is an absolute blizzard of fsync calls, several per file. Kernel 3.5 is better than 3.2 and supposedly 3.7 will be even better again. There is also the 'eatmydata' LD_PRELOAD wrapper which nulls out the fsync calls. It was worthwhile using on 3.2, and with 3.5 I don't bother.
That is write issues. I have no noticeable difference in read speeds, and they are limited to the speed of the underlying media, which is pretty much the case for any filesystem. In theory using compression will help for compressible files.
- mercurial 14y agoThanks for the detailed feedback, much appreciated.