> There is no working `fsck` and the existing repair tools come with dire warnings This stems from a misunderstanding. Fsck and fsck-adjacent tools have three

> There is no working `fsck` and the existing repair tools come with dire warnings 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.