Btrfs Deprecating Its Integrity Checker Tool

[Draget]

I read a lengthy article and I am not sure if it was from BTRFS devs or some other modern filesystem.

It was against tools to check or repair the filesystem. Mainly that there is a very mathematical approach of such a tool: A checker/repair tool can only act on invariants and deduce 'incorrect' states by reasoning about the whole filesystem. And this is simply impossible and snakeoil since the complexity of modern filesystems prevents implementing this correctly and it is impossible to know what property needs to change to make it 'correct'.

Now, it looks like code to check the integrity is deprecated because it is a maintenance burden.

Both of these things I feel not very comfortable about reading. My thoughts:
While the exact invariants (e.g. a size is not negative, a checksum is correct etc.) are complex, there are a lot of 'good estimates' one can do. Does the user have a 1TB disk which is provision for a 2 Exabyte filesystem? -> Should probably be added to the list of things the checker utility asks the user about if this is correct. And while some things cannot be fixed (the checksum of a file is broken?), there might be viable workarounds (Tell the user the exact files occupying these blocks and offer them to zero-out the blocks or do *something* that stops ongoing read-errors).

And I would expect that huge portions of the code that reason about the integrity are shared with the filesystem as well. And that they have a buttload of unit-tests for all of them.

And even if all the 'magically repairing' code is part of the driver itself, having a tool that simply lists me the files or kind of errors in a human readable format is psychologically nice. I have much less trust in a filesystem that one day says 'cannot read the file, something broken bro' instead of one where I regularly scan and get in advanced the message 'Yo, your porn collection is no longer readable because the disk has x defect sectors and there is no recovery/parity data.'. This would shift my view from 'That filesystem let me down when I needed my files' more to 'That filesystem at least told me which files are gone in time and gave me time to react'.

I know that 'scrubbing' is supposed to take over that role. But the output and options are different to FS-Checks where I could even run a quick, simple consistency check and not have to read/write through the whole disk every time.

Just my thoughts.

[CochainComplex]

7suq67.jpg

[Weasel]

All those cars, houses, tools... Maintenance burden. We should go back to living in caves and hunting. Oh wait... Spears are a maintenance burden as well...

Yeah, that was kinda the point.

[dkasak]

7stlir.jpg
Love btrfs. Couldn't resist

[oleid]

so I maintain myself

Not long and you'll be a maintenance burden as everybody will be at some point. And some time after that, you'll die and will turn to dust eventually.

[oleid]

I think btrfs is a maintenance burden too, let's remove it.

All those cars, houses, tools... Maintenance burden. We should go back to living in caves and hunting. Oh wait... Spears are a maintenance burden as well...

[PuckPoltergeist]

I think btrfs is a maintenance burden too, let's remove it.

Right, I think Weasel is a maintenance burden, let's remove it

[zexelon]

Well, it's the default filesystem for both Fedora and SUSE, it's heavily used at Meta (it's been mentioned as being the exclusive filesystem for their server fleet), it's the root filesystem in every Steam Deck, it's used by distributions like ChimeraOS to distribute new immutable root images, etc.

FWIW, the steam deck's use of BTRFS on the root FS is read only... The vast majority of file systems including super experimental ones are typically great in read only

I would personally feel very good about running my root folder on btrfs single disk read only!

[wikinevick]

btrfs was never about integrity.

[Nth_man]

[...] comments here are misguided attempts at starting a flame war.

starting with the name of the article of Phoronix.