It looks like it takes quite some time till it is fully implemented. Why should we start using it right now instead of btrfs/zfs?
I don't think anyone is suggesting you should.
Bcachefs: “the COW filesystem for Linux that won't eat your data”
11–20 of 110 posts
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#12It looks like it takes quite some time till it is fully implemented. Why should we start using it right now instead of btrfs/zfs?
You probably shouldn't. It's ready for adventurous testers, and is pretty stable, but unless you're willing to report bugs or hack on it, you can probably stay away.
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:
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#13>Snapshot implementation has been started, but snapshots are by far the most complex of the remaining features to implement Snapshots are the #1 feature of COW filesystems. I've been using them for a bit in btrfs and this feature is game-changing (and no, it hasn't eaten my data yet).
At first glance, the status page of btrfs look horrible:
https://btrfs.wiki.kernel.org/index.php/Status
The problem areas are mostly RAID and exotic features. RAID can be handled by a different layer and most users don't really need the exotic features.
Judging from the media silence in the last months I'd say either people stopped using btrfs or it just about works good enough for everbody.
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#14Curious, I didn't see mention of this, but perhaps someone here knows, is there TRIM support or planned support for bcachefs?
bcache originally supported discard/TRIM commands (toggled by mount options), but taking a quick look it might have been removed in bcachefs during the progress of development.
I imagine ultimately TRIM will be supported, though (I don't see a reason why it wouldn't be, and considering Kent is focused on hammering out the design I imagine it'll inevitably fit in well).
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#15>Snapshot implementation has been started, but snapshots are by far the most complex of the remaining features to implement Snapshots are the #1 feature of COW filesystems. I've been using them for a bit in btrfs and this feature is game-changing (and no, it hasn't eaten my data yet).
At first glance, the status page of btrfs look horrible: https://btrfs.wiki.kernel.org/index.php/Status The problem areas are mostly RAID and exotic features. RAID can be handled by a different layer and most users don't really need the exotic features. Judging from the media silence in the last months I'd say either people stopped using btrfs or it just about works good enough for everbody.
when the RAID is handled by a different layer you lose some very important integrity features
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#16I think ZFS is the only viable open source CoW total storage management option commercially. These new Linux filesystems are way too late to the party, and it will take a decade for them to reach maturity when they reach basic 1.0 feature parity.
In parallel I see XFS as the long term evolution for Linux file systems. It will continue to scale slightly up from where it sits today and address fail in place, flash, metadata checksums, snapshots etc where total storage management is done by overlays like HDFS, object stores, etc.
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#17>Snapshot implementation has been started, but snapshots are by far the most complex of the remaining features to implement Snapshots are the #1 feature of COW filesystems. I've been using them for a bit in btrfs and this feature is game-changing (and no, it hasn't eaten my data yet).
At first glance, the status page of btrfs look horrible: https://btrfs.wiki.kernel.org/index.php/Status The problem areas are mostly RAID and exotic features. RAID can be handled by a different layer and most users don't really need the exotic features. Judging from the media silence in the last months I'd say either people stopped using btrfs or it just about works good enough for everbody.
OpenSuSE uses btrfs by default and relies on it for one of it's killer features. Before a system change, such as installing updates, changing services configuration, etc, is made using YaST, snapper takes a snapshot of the root filesystem. If something breaks, just roll back to the previous working state.
I'd say that for the OpenSuSE folks, btrfs falls squarely into the "good enough" category.
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#18>Snapshot implementation has been started, but snapshots are by far the most complex of the remaining features to implement Snapshots are the #1 feature of COW filesystems. I've been using them for a bit in btrfs and this feature is game-changing (and no, it hasn't eaten my data yet).
At first glance, the status page of btrfs look horrible: https://btrfs.wiki.kernel.org/index.php/Status The problem areas are mostly RAID and exotic features. RAID can be handled by a different layer and most users don't really need the exotic features. Judging from the media silence in the last months I'd say either people stopped using btrfs or it just about works good enough for everbody.
If you're using large raid/jbod arrays then the chances are you're using zfs or hardware raid.
I wouldn't want to be the poor sucker supporting a large BTRFS array.
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#19Earlier quoted context omitted.
At first glance, the status page of btrfs look horrible: https://btrfs.wiki.kernel.org/index.php/Status The problem areas are mostly RAID and exotic features. RAID can be handled by a different layer and most users don't really need the exotic features. Judging from the media silence in the last months I'd say either people stopped using btrfs or it just about works good enough for everbody.
when the RAID is handled by a different layer you lose some very important integrity features
IIRC, doesn't BTRFS also allow you to do cool things like change RAID levels dynamically? (E.g. You can be running a 2-disk RAID-1 array, pop in another disk and tell BTRFS to make it a RAID-5 array instead, then a year later pop in 2 more disks and switch to RAID6, all with no downtime.) I imagine that wouldn't be possible if you were doing RAID at a different layer.
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#20Curious, I didn't see mention of this, but perhaps someone here knows, is there TRIM support or planned support for bcachefs?
TRIM isn't super important given bcache's write pattern (sequential writes to large aligned blocks). It doesn't do random overwrite in place of small blocks.