On Sun, 21 Apr 2019 19:41:02 +0200 Daniel Cegiełka <daniel.cegielka_AT_gmail.com> wrote:
> > What exactly disqualifies bcachefs as a general purpose filesystem?
>
> Kent Overstreet said he didn't test bcachefs on small setups. This is
> a filesystem designed for storage. It is therefore a competition for
> btrfs and zfs.
That it "wasn't designed for" is not synonymous for "won't work", or even
"is a bad idea". Linux (and more general, Unix) wasn't "designed for" most
tasks it's doing today.
> We have three main purpose filesystems:
> * reading - Speed is the key here.
> * writing - This is a very complex issue. Write operations should be
> atomic (see Raiser4). Data integrity should be checked at the memory
> level. And of course speed.
> * storage - Speed is not the most important factor here. The key is
> data integrity and their safe storage.
>
> ZFS, btrfs and bcachefs are filesystems that are intended for storage.
> These are horrible solutions if you want to use them for writing. Here
> you have a very interesting analysis of this problem:
>
> https://fmad.io/blog-packet-capture-filesystem.html
All filesystems are designed to store files; that's what they do. "Designed
for storage" doesn't really mean too much.
That link also doesn't say anything about ZFS, btrfs, or bcachefs.
That there is some reduced write performance under at least some cases may
actually be perfectly acceptable for many users. Many current filesystems
already made a lot of performance/reliability trade-offs.
I think a 10% write performance hit to prevent a 0.01% chance of corrupted
data is perfectly acceptable. 0.01% doesn't sound like a lot, but it means
one computer out of every 10 000. It's actually quite a lot, especially over
the span of decades.
I don't think there is a clear cut distinction between "indented for
storage" and "every day use" either. My laptop is currently storing a lot of
stuff: pictures of the last 7 months in New Zealand, various code projects
I've written, a lot of weblog posts, an unfinished book, all my emails,
password manager data, etc. etc.
I have backups for much of it of course, but if you back up silently
corrupted data then it'll still be corrupted.
I don't think bcachefs is the answer for all filesystem questions, but the
general principles seem pretty sound, and barring prohibitive performance
penalties or the like, it seems to be a good default for new systems,
including "regular every day systems".
Some people might still want to use xfs, ext4, JFS, or something else, and
that's perfectly reasonable, but IMHO it makes the most sense for the
default to be *safe*, rather than *fast*. bcachefs looks like the most
promising solution for that that.
Received on Mon Apr 22 2019 - 12:13:10 CEST