Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bcachefs: “the COW filesystem for Linux that won't eat your data”

bcachefs.org

Post reply on HN
Print view View original

1–10 of 110 posts

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#2

Post by boris »

>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).

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#3

Post by jethro_tell »

I like that we are seeing competition in this space. I think it's good for business.

I do however see some big red flags in the linked page:

> Starting from there, bcachefs development has prioritized incremental development, and keeping things stable, and aggressively fixing design issues as they are found

Which is it? Big design changes or stable FS?

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#4

Post by OD_ »

jethro_tell wrote: post #3

I like that we are seeing competition in this space. I think it's good for business. I do however see some big red flags in the linked page: > Starting from there, bcachefs development has prioritized incremental development, and keeping things stable, and aggressively fixing design issues as they are found Which is it? Big design changes or stable FS?

From what the developer has stated on reddit, it's more like he wants to aggressively make changes on the filesystem right now, before any attempt at mainlining into the kernel, to not end up like btrfs, which in his view, was mainlined prematurely.

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#5

Post by ysleepy »

While I really like these sort of file systems, I'm not holding my breath.

This isn't a simple filesystem project, but plays in the next-gen space ZFS opened up. There will be a lot to do, especially IO scheduling, RAID safety with shitty drive firmwares, consistency guarantees with fsync/partial flushes etc.

I'm pessimistic about it being mainlined in the near future, the core team will be weary of a second btrfs.

What I would like to see is a APFS/exFAT crossover with COW and data checksums without all the volume mgmt with ports for all possible operating systems so everyone can use it for their SDcards, usb-sticks and external drives without making tradeoffs and using fuse.

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#6

Post by bryanlarsen »

jethro_tell wrote: post #3

I like that we are seeing competition in this space. I think it's good for business. I do however see some big red flags in the linked page: > Starting from there, bcachefs development has prioritized incremental development, and keeping things stable, and aggressively fixing design issues as they are found Which is it? Big design changes or stable FS?

My impression was that the base, bcache, is stable. The file system layer, bcachefs, has big design changes

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#8

Post by gbrown_ »

ysleepy wrote: post #5

While I really like these sort of file systems, I'm not holding my breath. This isn't a simple filesystem project, but plays in the next-gen space ZFS opened up. There will be a lot to do, especially IO scheduling, RAID safety with shitty drive firmwares, consistency guarantees with fsync/partial flushes etc. I'm pessimistic about it being mainlined in the near future, the core team will be weary of a second btrfs. W…

> with COW and data checksums without all the volume mgmt

The fact that the raidz volume is not an opaque block device allows ZFS to be aware of data corruption when comparing checksums and self heal if the data can be re-constructed from the array.

I'm not saying any attempt at a new filesystem should have to bundle the two layers together, but they should allow for communication between the abstractions.

Post reply on HN