Re:Bcachefs: “the COW filesystem for Linux that won't eat yo...
by h2hn on Wednesday March 22, 2017 @06:52PM
(#13935790)
I spent the last week testing ext4/btrfs/zfs on Linux and I found that zfs is rather slow and btrfs has improved its performance a lot in the last years (I should refined the script a bit, upload some graphics and make a post).
https://gist.github.com/liloman/d525131fab9b9a440140905921e9...
I'll give it a try on bcachefs. :)
The script needs a 512MB spare disk partition and some basic changes but the fundamental work is there.
There are reasons to still want it, despite its newness; for example, the latest updates bring huge improvements in metadata efficiency (low metadata overhead -> more metadata in the cache -> larger working set). Someone on the IRC channel reported it's somewhere around 20x faster than most filesystems when it comes to "iterate millions of files recursively", blowing everything else out of the water. (This seems somewhat synthetic, and I'd say it mostly is -- but OTOH, "tons of files in a directory" being really slow is life, and has bitten me multiple times in a prior job). In general, improved metadata efficiency helps everywhere, though. For example, if you're doing backups on a really big filesystem recursively, you'll have to traverse the metadata inodes a lot to get e.g. last modified time. bcachefs will likely do awesome here in terms of performance.
Another unique feature I recall is the fact it has very very good tail latency -- bcachefs almost never blocks on I/O unncessarily, so you do not get random 'lag spikes' when things like the page cache get flushed out (which may halt some other I/O ops). This makes the system feel much more consistent, in general.
There's lots of good info in the architecture document and Patreon posts from Kent:
http://bcachefs.org/Architecture/
https://www.patreon.com/bcachefs/posts