LWN: Comments on "The first part of the 6.15 merge window"

Is self-healing always good?

koverstreet — Thu, 03 Apr 2025 13:59:19 +0000

Well, this isn't btrfs - we don't do that.

There are cases where fsck will delete things, but for the most part that's only if we have another piece of metadata that says "this shouldn't exist".

e.g., extent past the end of an inode - something went wrong with truncate.

If a reflink pointer points to a missing indirect extent, we just mark it as poisoned, so on future attempts to read from it we don't have to print out the same error, and we can un-poison it if the indirect extent comes back; this guards against a temporary lookup error in the reflink btree.

For the snapshots btree, a key for a snapshot node that doesn't exist generally indicates a problem with snapshot deletion, and the key will be deleted. But we also track when a btree has lost data (topology error, IO error), and if the snapshots btree has lost data we'll instead try to reconstruct snapshot tree nodes (and also subvolume keys, etc.).

We can reconstruct inodes if the inodes btree has lost data (permissions, ownership, timestamps etc. will all be wrong, and i_size will be a bit off but you'll still have the correct file contents).

This topic is an area of future research, but for all practical purposes we're in good shape.

the self healing work continues in bcachefs

koverstreet — Thu, 03 Apr 2025 13:52:01 +0000

What's missing in this case?

the self healing work continues in bcachefs

DemiMarie — Thu, 03 Apr 2025 08:06:53 +0000

Will bcachefs be able to completely recover (no data loss) if all data is present on a quorum of replicas?

Is self-healing always good?

DemiMarie — Thu, 03 Apr 2025 08:03:52 +0000

Is self-healing always wanted? My concerns are:

It could risk trashing good-but-unreachable data, preventing subsequent data recovery operations.
It could hide errors from userspace, such as by reporting “file definitely does not exist” instead of “I/O error occurred and we don’t know if the file exists”.
It could recover data that was never actually present, such as freed disk blocks, creating a security concern.

If the filesystem can’t tell if file X should be there or not, or is uncertain as to what its contents should be, I would prefer that all attempts to access X fail with something other than -ENOENT until and unless the administrator tells the filesystem to use its best guess of what the pre-corruption situation was, or X is overwritten by an operation that makes that state irrelevant. Silently returning wrong data is the worst possible outcome.

the self healing work continues in bcachefs

koverstreet — Mon, 31 Mar 2025 04:57:18 +0000

I'm not anti systemd, but no

the self healing work continues in bcachefs

jmalcolm — Mon, 31 Mar 2025 04:23:04 +0000

Is systemd going to be a requirement for bcachefs?

the self healing work continues in bcachefs

koverstreet — Mon, 31 Mar 2025 03:09:25 +0000

Not quite :) but anything within the realm of possible, yes. If there's still extents and dirents leaf nodes, we should get you a working filesystem with everything possible intact.

We regularly recover from extreme disaster scenarios today - I've been looking at a metadata dump where it looked like a head just skated across the platter, which created some very... particular alloc info inconsistencies, but that's been the only failure to repair in ~6 months, and I've seen logs of some good ones. So that's largely done.

Once the mount API extension happens, plus better communication between the mount helper and systemd/plymouth (because of course communicating things to the user has been getting more complicated), we'll even be able to tell the user "hey, your SSD crapped itself (X IO errors, toast btree nodes), please wait while we reconstruct btree roots/alloc/what have you, here's a progress bar"

And this stuff is pretty fast, too - post 6.14 that dealt with backpointers check/repair. Even btree node scan is fast thanks to a small bitmap in the superblock, if we lose btree roots.

Further off, post experimental, will be finishing off online fsck - and then we'll be able to recover from slightly absurd levels of damage in the background while your filesystem is RW. (People with huge arrays really want this).

the self healing work continues in bcachefs

motk — Sun, 30 Mar 2025 22:59:17 +0000

True vacuum universe ending events? A bold claim.

bcachefs news

alison — Sat, 29 Mar 2025 17:11:04 +0000

> never stop coding :)

Words to live by!

-- Alison

bcachefs news

koverstreet — Sat, 29 Mar 2025 05:41:13 +0000

never stop coding :)

bcachefs news

alison — Sat, 29 Mar 2025 05:19:50 +0000

I see that Kent Overstreet is back, assuming that he was ever actually away.

the self healing work continues in bcachefs

koverstreet — Sat, 29 Mar 2025 05:09:28 +0000

the goal is a filesystem that can recover from /anything/

Meticulously undocumented

nijhof — Fri, 28 Mar 2025 22:13:18 +0000

Is meticulously undocumented more or less undocumented than rigorously undocumented?