Casefolding For Bcachefs File-System Posted

[Quackdoc]

Casefolding is one of the more important feature. I myself am of the opinion that I wish linux itself would default and run as case folded but alas, I know that won't happen. Am really excited for bcachefs, even though I only want to use it on single drive systems, having cow that isn't zfs or btrfs will be really nice. XFS is good bridge for features for a temporary stopgap

[Britoid]

Such as?

There is the inode32 thing, but bcachefs has an inode32 compat mode.

well on xfs inodes (which you can work around), weird quirks and case folding see https://www.reddit.com/r/linux_gamin...es_stating_no/

To resolve you have to reformat the partition with various non-default settings.

[osw89]

Not only does F2FS have lz4 compression, it has highly granular compression controls for tuning compression types based on file extension.

Unless they changed it since I looked into it in 2021 F2FS's compression implementation doesn't let you use the space saved by compression, nor can you determine the compression ratio. It's just there to minimize writes to the disk. Not that it's a general indicator of bad quality but I was using F2FS with ZSTD compression back then just for the compression, the volume somehow destroyed itself(reading big files >5GB always failed) but it was backed up thankfully.

This and the previous fact made me switch to ZFS and it has been working fine since. It would be good to have a low overhead, non-CoW FS with proper transparent compression support sometime because ZFS on a single disk is honestly overkill.

[brucethemoose]

Not only does F2FS have lz4 compression, it has highly granular compression controls for tuning compression types based on file extension. Edit to add: If you want snapshot roll backs on flash based storage, you're probably better off with nilfs2... at least once they get a working fsck.

As for BtrFS... aside from legit data integrity questions with the filesystem there's several, including btrfs_check being incomplete and unreliable according to the Arch Wiki along with it's quite atrocious performance compared to alternatives and arguably an inappropriate choice for single device storage on portable systems, I've seen SteamPlay/Linux games in Steam that crash on any FS other than ext4. No idea why, I never followed up on what was going on - it shouldn't matter what the underlying FS is, but it does.

F2FS compression does not save space, unless you manually make the compressed files immutable.

Also it has a relatively short file extension limit... I can't remember what it is exactly, as its not documented, and I had to find it in the source when I ran into it.

As for the crashes, some games are unhappy without casefolding (which is on by default in Windows). But this may not be the issue, as its not enabled in ext4 by default, and IIRC proton takes care of it anyway.

[ireri]

do you have a link to this list?
also, kernel older than 5.x are VERY old: a big amount of work has been done in the btrfs code since then.

Yes, I do have a link, but I don't believe you could be genuinely interested, as searching for it is as easy as looking for "debian btrfs" in the engine of your preference and hitting the first result.

And you are right on the kernel version while it can be old for some, you must realize that it actually isn't for some environments; in any case, as I said, that's one edge case, I included it as an example.

[JEBjames]

Michael

Typo "on tbe Bcachefs file-system" should be "on the Bcachefs file-system"

[Michael]

Michael

Typo "on tbe Bcachefs file-system" should be "on the Bcachefs file-system"

Whoops, thanks as always!

[F.Ultra]

Yes, I do have a link, but I don't believe you could be genuinely interested, as searching for it is as easy as looking for "debian btrfs" in the engine of your preference and hitting the first result.

And you are right on the kernel version while it can be old for some, you must realize that it actually isn't for some environments; in any case, as I said, that's one edge case, I included it as an example.

Do you mean this link: https://wiki.debian.org/Btrfs ? The list of "other warnings" on that page doesn't really support this idea that btrfs would wreck you data on Debian even on 5.x kernels.

[cynic]

Yes, I do have a link, but I don't believe you could be genuinely interested, as searching for it is as easy as looking for "debian btrfs" in the engine of your preference and hitting the first result.

well, you're actually accusing me of not being genuine here, but if https://wiki.debian.org/Btrfs is the "list" you're referring to, then it's you not being genuine here.

* firstale, what you're referring to as "a list of btrfs problems" is just a documentation wiki page.
* secondly, is not at all regarding "problem related to btrfs".

The only few problems listed there are either:

* interaction with other tools (ie: bcache, LVM) that are directly attributable to them
* regarding VERY old kernel version

all the rest are good practices, advices and features documentation.

these are just some "problems" copied and pasted from the page:

* "Many people have experienced upwards of six years of btrfs usage without issue"
* "Does btrfs really protect my data from hard drive corruption? Yes"
* "Does btrfs work on RaspberryPi? Yes, possibly improving filesystem I/O responsiveness."

And you are right on the kernel version while it can be old for some, you must realize that it actually isn't for some environments; in any case, as I said, that's one edge case, I included it as an example.

what does it mean "it isn't for some environments"?
There are environments where XFS is not fit, or environments where not even Linux is fit.
So what?

Should we take the XFS documentation page, call it a list of problems, and post everytime there's a filesystem article on Phoronix?

[WereCatf]

Do you mean this link: https://wiki.debian.org/Btrfs ? The list of "other warnings" on that page doesn't really support this idea that btrfs would wreck you data on Debian even on 5.x kernels.

I haven't had Btrfs wreck any data in a long, long time now, but I can make Btrfs hard crash quite easily on 5.15 under Ubuntu 22.04 LTS. A hard crash at the filesystem level is still pretty bad, regardless of whether any data gets wrecked or not, IMO.

I haven't yet gotten around to trying if a 6.x series kernel still exhibits the same issue.