Bcachefs File-System Re-Submitted For Linux 6.6

[pWe00Iri3e7Z9lHOX2Qx]

<crosses fingers and prays to any deity who will listen>

[Old Grouch]

I too would like to see a Linux block-layer device that implemented configurable forward error correction transparently. I have seen a python fuse implementation, but a proper kernel block driver would be a nice-to-have.
Similarly, I really, really like the NILFS continual snapshotting* (every synchronous write, plus a configurable timer-based snapshot, the default being every 'every few seconds'). I use it as a substitute for a proper file-versioning file system.



*It's not snapshotting, but checkpointing, but any checkpoint can be converted into a snapshot.

[curfew]

BFS is out; duplicates the name of a Linux scheduler.

BCFS appears to be unused in Linux, but the name is close to a 'bcftools' project/application.

There once was a JFS in Linux; have not used that one in decades. And XFS & ZFS would duplicate an active projects/filesystems.

Are people really so simpleminded that they can only invent names based on the underlying technologies and then dropping a few letter along the way?

Hans Reiser at least used his imagination.

[stiiixy]

Are people really so simpleminded that they can only invent names based on the underlying technologies and then dropping a few letter along the way?

Hans Reiser at least used his imagination.

By using his own name.

That's not really imagination.

I've been so drunk as to come up with an entire novel in six hours. I didnt bother typing my own name because I felt that was unnecessary, egotistical and if my tripe ever saw light of say, I'd be condemned to an 'Asylum for SexyFS people'.

Also, Zed eff ess. It's how you're SUPPOSED to pronounce it.

I almost can't bring myself to quote an old movie like Skeevy's oldmanitis, but heyhooo, Zed's dead baby.... to support my monologue. As ZFS surely is not dead.

[Old Grouch]

Are people really so simpleminded that they can only invent names based on the underlying technologies and then dropping a few letter along the way?

Hans Reiser at least used his imagination.

Ye

How about Cabinet of Wonders File System - COWFS?
Or FWAIN? *
Or Murgatroyd, that's a good, memorable name.
Or use standard marketing brainstorming, along the lines of colour, geometric shape, animal, such as Blue Square Fish File System, or Cherise Triangular Gibbon FS, or Octarine Pentangular Librarian FS

Or follow Iain M. Banks approach, and call it something like Ultimate Filesystem the Second.




*Think scanners

[flower]

It is certainly possible, but it will get very slow with any CoW filesystem, be it btrfs, ZFS or another. The solution is to disable CoW for the disk image files only. Btrfs allows that, don't know about ZFS or bcachefs.

my vm's run very well on zfs though. without disabling cow.
they also did run very well on lvm+snapshots and dm-integrity

it was only on btrfs where i had that problem. but still: that was a few years ago

[Khrundel]

• RAID => DM-RAID, MDADM
• Tiered storage => DM-Cache, Bcache
• Encryption => DM-Crypt
• Integrity => DM-Integrity

Keep things as simple as possible, but not simpler.
DM-RAID is already.. well, obsolete. You don't want a number of identical drives within your PC. Thats why btrfs was implemented.
DM-Cache and Bcache are bad because they can't work effectively with any COW system. Look, imagine for example content of ~/.cache, it contains files which are frequently used, so their extents will end up within SSD tier, but eventually all these files will be overwritten. With Ext4/Bcache this can be addressed with inplace replacement or with TRIM command, but COW filesystem does not trim or replace old data, it is stored withing snapshots. So outdated data will waste SSD space until usual MRU mechanism will decide it is not needed anymore. It can be fixed with some "stop caching this extent" command, but it is stupid to create some general interface only to communicate between btrfs and bcache.
Also it is good to cache metadata, it would be useful to be able to control caching with btrfs subvolumes or with extended attributes, with bigger SSDs it would be useful not to duplicate data between HDDs in case it is already stored on SSDs, also there are plenty of SMR harddrives which is impossible to use to store something which updates frequently but they well suit to store something not modified. So tiered storage support is must have for btrfs or btrfs-like filesystem. Btrfs developers do not want to add this, well, maybe bcachefs will show it is a good idea.

[vandelay]

Glad to see the ML is much more civilized this time, hope it stays that way, I saw christian brauner mention the below which is very fair IMO

What he says about 6.7 not being too far away may be true for them, but not for end users who want to start using and testing it if 6.6 ends up being the next LTS kernel. This is just my selfish request but I am hoping to start using it for some non-critical data on my NAS.

[szymon_g]

holy crap after reading the first two pages i'm so glad i'm not the only one who thought that bcachefs was sort of, well, cashing FS, something somehow similar to tmpfs or something like that - and not a general purpose file system.

also- providing it would be included in mainline, what are its benefits over ext4, xfs or even btrfs?

[szymon_g]

BeachFS? Oo ⛱️🗃️

or, how many non native English speakers will say, BitchFS