Re:Bcachefs Merged into the Linux 6.7 Kernel
by lproven on Wednesday November 01, 2023 @08:33AM
(#38097370)
See my reply below.
I disagree.
You seem to be attempting to justify a profound failing by quibbling about the meaning of words or commands.
The real problem is: Btrfs corrupts readily, and it lacks tools to fix the corruption.
What the tools are called, what their functional role is theoretically meant to be, and whether this is justified in a tool of a given name is tangential and relatively speaking unimportant.
Re:Bcachefs Merged into the Linux 6.7 Kernel
by curt15 on Wednesday November 01, 2023 @02:49PM
(#38103062)
>The real problem is: Btrfs corrupts readily, and it lacks tools to fix the corruption.
Here's a recent example of corruption unearthed by users after Fedora started defaulting to btrfs: https://bugzilla.redhat.com/show_bug.cgi?id=2169947.
This stems from a misunderstanding. Fsck and fsck-adjacent tools have three purposes:
1. Replay journal entries in a journalled filesystem, so that the filesystem is repaired to a good state for mounting
2. Scrub through checksums and recover any data/metadata that has a redundant copy
3. In rare cases, a fsck tool encountering invalid data can make guesses as to how the filesystems should be structured -- basically, shot in the dark attempts at recovery.
Btrfs does not need #1 because it is not journalled. Assuming write barriers are working, any partially written copy of the filesystem is valid and will simply appear as if the pending writes had been rolled back. This aspect alone greatly diminishes the need for a fsck tool that filesystems like ext4 have.
As for #2, Btrfs already has scrub support. No issues there.
As for #3, it's questionable whether you should ever rely on such functionality, and fsck tools that do implement such functionality tend to have little maneuverability in the first place.