Bcachefs, an Introduction/Exploration

Re:Bcachefs, an Introduction/Exploration by bheadmaster on Friday July 26, 2024 @03:54AM (#41076674)

Development taking long usually means that the model itself is too complicated to be done right in a reasonable time, which indicates that the "stable" implementation could still be buggy, but only if you stray away from the common path. It's hard to feel comfortable using such a software in a fundamental role such a file system.

[ Parent | on HN ]

Re:Bcachefs, an Introduction/Exploration by 7e on Friday July 26, 2024 @04:08AM (#41076751)

In this case I think it’s the case that bcachefs has only a very small set of developers working in it.

[ Parent | on HN ]

Re:Bcachefs, an Introduction/Exploration by jeltz on Friday July 26, 2024 @04:59AM (#41076983)

But that was not the case for btrfs.

[ Parent | on HN ]

Re:Bcachefs, an Introduction/Exploration by humanfromearth9 on Friday July 26, 2024 @04:46AM (#41076920)

I think it's not quite so simple. The problem of organising storage is at least complex, on a scale of "simple complicated complex chaotic". The inherent complexity might be impossible to reduce to something simple or even just complicated, except _maybe_ with layering (à la LVM2), each layer tackling one issue independently of the others. But then it's probably at the cost of performance and other efficiency. Each layer should work such that it does not interfere too much with the performance of other layers. Not easy.

Given the rather cheap price of durable storage these days, I would favour rock solid, high quality code for storing my data, at the expense of some optimisations. Then again, I still like RAID, instantaneous snapshots, COW, encryption, xattr, resizable partitions, CRC... It's it possible to have all this with acceptable performance and simple code bricks combined and layered on top of each other?

[ Parent | on HN ]

Re:Bcachefs, an Introduction/Exploration by dspillett on Friday July 26, 2024 @07:19AM (#41077683)

> which indicates that the "stable" implementation could still be buggy, but only if you stray away from the common path

Or that the complexity is such that if a new bug is found, it may take a long time to be fixed because of the complexity, or it is fixed fast and has unexpected knock-on effects even for circumstances on the common path.

Something that takes a long time to be declared stable/reliable because of its complexity, needs to spend a long time after that declaration without significant issues before I'll actually trust it. Things like btrfs definitely live in this category.

bcachefs even won't be something I use for important storage until it has been battle-tested a bit more for a bit longer, though at this point it is much more likely to take over from my current simple ext4-on-RAID arrangement (and when/if it does, my backups might stay on ext4-on-RAID even longer).

[ Parent | on HN ]

Re:Bcachefs, an Introduction/Exploration by riku_iki on Friday July 26, 2024 @01:56PM (#41080697)

> Development taking long usually means that the model itself is too complicated to be done right in a reasonable time

yeah, features rich/complete fs is complicated, that's why we have very few of them.

[ Parent | on HN ]