[bug] fsck refuses to repair damaged UFS using backup superblock

[Warner Losh]

On Sun, Nov 25, 2018, 11:35 AM Kirk McKusick <mckusick at mckusick.com wrote:

> > From: Rick Macklem <rmacklem at uoguelph.ca>
> > To: "soralx at cydem.org" <soralx at cydem.org>,
> >         Kirk McKusick <mckusick at mckusick.com>
> > CC: "freebsd-fs at freebsd.org" <freebsd-fs at freebsd.org>,
> >         "Julian H. Stacey"
> >       <jhs at berklix.com>
> > Subject: Re: [bug] fsck refuses to repair damaged UFS using backup
> superblock
> > Date: Sun, 25 Nov 2018 15:25:21 +0000
> >
> >> Kirk McKusick wrote:
> >>
> >> Below is a proposed fix for fsck_ffs to properly handle superblock
> >> check-hash failures (notably to optionally search for a usable
> >> alternate superblock). Let me know if you still have a filesystem
> >> on which you can test it, and if so whether it works correctly.
> >
> > As above, I think you can reproduce this by running an older kernel
> > that mounts the file system. I ended up re-installing when I ran
> > into this yesterday (no biggy, it was just a test machine). It
> > happened after I had been running a kernel built from stable/12 on
> > the system and then tried to boot it.  (Since the root fs got these
> > errors, I couldn't boot any kernel on the root fs.)
>
> Kernels before -r339671 clear the CK_SUPERBLOCK flag in the superblock.
> Kernels at and after -r339671 ignore the check-hash if the CK_SUPERBLOCK
> flag is clear. So you should be able to run on older kernels without
> causing superblock check-hash failures on later kernels. Fsck will offer
> to enable the superblock check-hash if you are running on a kernel at
> or newer than -r339671.
>
> > It would be nice if there was a way to override the check and boot
> > the system.  (Is a loader tunable reasonable for this?)
> >
> > rick
>
> I have fixed the problem with fsck being unable to check filesystems
> with check-hash failures in -r340925.
>
> Rather than adding a loader tunable to override the check (which people
> would have to track down in the midst of a crisis), it might be better
> to simply have the loader print a warning when there is a mismatch and
> proceed to try using the filesystem. If successful, an fsck could then
> be run to try and clean it up. Does this seem reasonable?
>

Yes. You have a big chicken and egg issue otherwise.  And not booting seems
like an extreme overreaction to a bad checksum. I can think of no use case
where you'd want it. Let's let people ask for it with a decent use case
before we do anything more than print a warning and soldier on...

Warner

        Kirk McKusick
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>