bcachefs

[Zucca]

I posted this mainly because a binned spam message made a forum bug appear on this topic.

Anyways... I think I'll deploy btrfs then on my setups which need a big, multi disk, storage portion.
I nomally use LVM+XFS on my setups that are simple one or two disk systems.
I'll put btrfs on areas which are for storage and backups.

bcachefs shall stay in the shelf as long as it's out of tree. Just like ZFS.
I just don't want the hazzle.

[logrusx]

I don't think COW FS are strong or even intended for storage and backup. Their main strength is durability.

They also use a lot of space precisely because of the copy on wire.

You're not likely to experience any of their advantages with such usage.

Best Regards,
Georgi

[Zucca]

I've used btrfs for local backups before and it worked beautifully there.
Incremental daily/hourly backups that specifically utilize COW and/or reflinks are like meant to be used with btrfs or similar fs.
btrfs backups have saved me several times. And the redundancy features too... I've pulled the wrong drive from the stack few times...

For external disks I tend to use XFS.

Reflinking and other such dedup functionalities might lower the reliability on spinning rust, but with modern SSDs that turns more like into advantage.

The downside of btrfs is its speed. scrubbing and balancing take a lot of time.

[pjp]

bcachefs shall stay in the shelf as long as it's out of tree. Just like ZFS.
I just don't want the hazzle.

Is there no way to put them "in tree"? I thought the issue was one of distribution, not undistributed inclusion.

[Hu]

It was in the kernel tree, until a dispute between Linus and the bcachefs maintainer ended in it being removed. This is referenced to some degree in posts a few months ago in this thread.

[pietinger]

Linus haven't accepted patches for bcachefs in 6.17 (and marked it as 'externally maintained') and has it removed entirely in 6.18 ->
https://git.kernel.org/pub/scm/linux/ke ... cc247495cd

[pjp]

Yeah, I meant merging it downstream. Instead of gentoo-sources (only used as an example), there's official-kernel-sources, unholy-sources, and the means by which they can be merged locally (not distributed) and built. The faffing about with "external modules" seems the hard way to do it.

[Hu]

I am not aware of a licensing reason someone could not produce and distribute a combined bcachefs + Linus kernel. The problem is that since bcachefs is not in Linus' tree, there is no expectation that people making tree-wide changes need to examine bcachefs and update it for compatibility with their changes. That makes bcachefs vulnerable to the same form of bitrot that users of the nVidia proprietary driver suffered for years, where most new kernel versions contained at least one API change that broke the out-of-tree nVidia code. That situation may also mean fewer users testing bcachefs, and so a higher risk that any regressions are not reported and fixed in a timely manner. Such regressions need not come from mistakes by the bcachefs author(s). They could also come from a tree-wide change that alters the semantics of an API, without altering its call signature. In such a case, the compiler will allow mixing the pre-change bcachefs with a post-change kernel, but the results at runtime would be wrong.

[Zucca]

https://poc.bcachefs.org/

So. Kent's been toying with his own LLM.
I saw some commits done by Kent, Claude and this POC.

... and it seems he's really deep in this.

Some of the commits are done by LLM alone.

Oh boy... There's way too much off in all this.