Bcachefs Merged Into The Linux 6.7 Kernel

[timofonic]

Didn't you get the memo about CoW filesystems being one of those "Ride or Die" kinda deals?

Why people are so extremists?

[Old Grouch]

Why people are so extremists?

It's a side effect of posting in forums where interactions with people are not physically face to face. People feel freer to use more inflammatory language and adopt more polarised positions that they do when interacting with people in their physical presence.
There doesn't seem to be a good counter to it, other than heavy moderation, which many people dislike.

If you find some posters beyond your tolerance level, it is possible to set the forum to not show posts made by particular usernames.

Some people appear to have abrasive personalities, and no wish to change them. The reasons for this can be varied. Part of life is developing your own coping mechanisms for dealing with people like that. I hope you find one that works for you.

[royce]

oh, I wonder if the fact that my openzfs-based ubuntu eats my whole memory after a week or two of uptime has something to do with that. it doesn't behave like that when it's on lvm/ext4 or xfs

ZFS in memory cache system is called ARC and is separate from Linux' cache system, that's why it looks as if it's eating RAM. Cache memory is returned to the system when needed, although not as swiftly as Linux cache and you can run into oom.

That ZFS needs 1GB of RAM per TB is an urban myth. ZFS uses by default half your RAM for ARC, but this is configurable to match your use case. Specifically, file deduplication is memory intensive, but it is seldom worth the hassle.

For instance my home NAS doesn't have massive performance requirements and is configured with 6GB out of 32 for ARC, and this is enough not just for the root pool but also the spinning rust storage pools. My laptop is equally configured with just 4GB for ARC (ZFS root pool as well) as it already has fast NVME storage and with my use case a large ARC cache is somewhat redundant. The reason I limit those is because as I mentioned oom can occur when ARC isn't emptied fast enough during memory pressure (an unfortunate consequence of being separate from Linux cache) and I run a number of VMs which also need large chunks of the host's system memory.

You need to tune ZFS for each use case. It's not a casual filesystem.

[royce]

"A special VDEV for faster metadata" so some special setup? So I don't think that refers to my statement about "default config".

There is no such thing as "default config" when it comes to ZFS. It's a specialist filesystem that needs you to put in the work to really be useful.

How big was it? I mentioned 20TB harddisks, which would according to the rule of thumb need 20gb to run smooth. Again with tweaking the settings there is probably lot possible (maybe more recently and not when zfs started out).

See my comment above. This "rule of thumb" is an urban myth.

[timofonic]

What about back on topic?

I see there's still a flux of patches here: https://lore.kernel.org/linux-bcachefs/

Anyone able to explain how Bcachefs is evolving after merge? I'm not used to Linux kernel development stuff, so it seems too chaotic and complex for me to properly follow it.

[blackiwid]

There is no such thing as "default config" when it comes to ZFS. It's a specialist filesystem that needs you to put in the work to really be useful.

Well I don't consider choosing a raid level as special setup, but tuning some setup I see, I also see it as a major disadvantage if I have to fiddle with btrfs for virtual machine files, deactivating what was it COW? Or something to have not total dogshit performance. That is not acceptable requirements for me for a filesystem.

See my comment above. This "rule of thumb" is an urban myth.

Maybe but this myth doesn't come from ZFS haters but ZFS Users and it's probably influenced from the hype and advocacy of many ZFS users of freebsd that needs absolutely minimum of 8gb ram and better 16gb to run good.

It shows how big of biased fanboys ZFS users were back around 2010-2014 because before ZOL and back then high ram systems were more expensive, yet they not only often switched away from Linux for a filesystem but also justified this absurd powerful machines as minimum requirement because ZFS back then only did run on BSD therefor the FS requirement indirectly was high amounts of ram.

Extreme Fanboyim brought them far, but apparently we have a second competitor with the huge advantage to be in-kernel, so it's days are numbered. Not for some people having for many years legacy setups, but for people go out of their way choosing special linux distros or setup this extra stuff to make it workable.

Of course many not switched away to linux for it but many are GPL haters and BSD Lisence / OS lovers, so why should I care for such a community I 100% disagree with even ideologic and technical.

Yet the same linux hater group (not all but a big chunk of it) need linux to make the FS usable without huge amount of ram the irony.

[timofonic]

Why so many people jihack this forum thread?

Any volunteer willing to talk about Bcachefs?

[EphemeralEft]

Why so many people jihack this forum thread?

Any volunteer willing to talk about Bcachefs?

BcacheFS is to BTRFS as Sacharin is to Aspartame; many people have an irrational fear of or hatred for one so they flock to the other, despite them basically doing the same thing and having the same issues. I think they both even use b-trees internally, so I really don’t know what the difference is.

That being said, if it increases the market share of CoW then I’m glad. I just hope it doesn’t fragment the development efforts for BTRFS. My guess is that any good features exclusive to BcacheFS will be ported to BTRFS, and then it’ll die like ReiserFS.

[timofonic]

BcacheFS is to BTRFS as Sacharin is to Aspartame; many people have an irrational fear of or hatred for one so they flock to the other, despite them basically doing the same thing and having the same issues. I think they both even use b-trees internally, so I really don’t know what the difference is.

That being said, if it increases the market share of CoW then I’m glad. I just hope it doesn’t fragment the development efforts for BTRFS. My guess is that any good features exclusive to BcacheFS will be ported to BTRFS, and then it’ll die like ReiserFS.

Doubting about the future of Bcachefs is irrational too. Btrfs has Oracle and Facebook. Also, criticism may be confused with hate too.

[pkese]

BcacheFS is to BTRFS as Sacharin is to Aspartame; many people have an irrational fear of or hatred for one so they flock to the other, despite them basically doing the same thing and having the same issues. I think they both even use b-trees internally, so I really don’t know what the difference is.

They do both use b-trees but in a very different way.

Btrfs uses 16kB b-tree nodes and rewrites the whole tree (from modified branch all the way up to the root) after each modification (there are of course optimizations to do this efficiently).

Bcachefs on the other hand uses 256kB b-tree nodes and each of these nodes contains a log structured data-structure (almost like a small database) which can be appended to without rewriting the whole node. This also means that the whole tree is much shallower (it takes less reads to get all the way down to the leaf) and it will be less write intensive on the disk.

I'll be keeping my btrfs for a while, but I find bcachefs as an extremely interesting development.
Its architecture is sane, however as usually, the devil is in the details.