On Tue, Feb 23, 2021 at 2:26 PM pmkellly(a)frontier.com
<pmkellly(a)frontier.com> wrote:
I recall a long and detailed discussion on this list before F33 was
released concerning what disk maintenance would be required with BTRFS.
As I recall, the final word was along the lines the running Scrub and
the other BTRFS utilities wouldn't be necessary since it was being set
up so maintenance shouldn't be needed.
Correct. Most of the time, for most users, what's provided is self
maintaining in Brfs kernel code. If there's necessary maintenance not
provided by the kernel, then it should be scheduled, e.g. a systemd
timer kicks off a service unit.
There was also some hesitancy to
call for running scrub because, depending on how often it's run Scrub
can be hard on SSDs (they wear out faster).
Scrub is mostly a read-only operation involving the verification of
checksums for all file system metadata and file data. There's no
concern on wear, you could run it every day if you wanted to.
But other considerations are how long it will take, how much CPU is
used, and will it slow down the computer until it completes?
Hmmm... Now that seems to be changing. I guess we better revisit the
BTRFS maintenance issue again. The first part is: Was this a surprise
one-off due to operator error or similar? Do we have a problem and BTRFS
maintenance will be required?
Scrub is not going to fix George's file system. I want to know if
there's more corruption than this one block, because I want to know
the big picture. The specific corruptions can provide clues for why
they are happening.
If this is the only bad block, there is a way to fix it with e2fs
tools. But getting a copy of this superblock before repairing it might
give a clue what stepped on it after btrfs-convert.
--
Chris Murphy