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

Rick Macklem rmacklem at uoguelph.ca
Wed Nov 28 01:31:32 UTC 2018


Kirk McKusick wrote:
>> From: Warner Losh <imp at bsdimp.com>
>> Date: Sun, 25 Nov 2018 12:01:45 -0700
>> Subject: Re: [bug] fsck refuses to repair damaged UFS using backup superblock
>> To: Kirk McKusick <mckusick at mckusick.com>
>> Cc: Rick Macklem <rmacklem at uoguelph.ca>, FreeBSD FS <freebsd-fs at freebsd.org>,
>>         "Julian H. Stacey" <jhs at berklix.com>,
>>         "soralx at cydem.org" <soralx at cydem.org>
>>
>> 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
>>>>
>>>> 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
>>>
>>> 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?
>>>
>>>      Kirk McKusick
>>
>> 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
>
>My proposal is that when a filesystem is being mounted read-only
>that superblock check-hash failures should be warnings only. This
>is true not just at boot time, but always. We should probably set
>the FS_NEEDSFSCK flag so that if it is updated to read-write a
>warning will get printed. Since booting always starts up with
>the filesystem in read-only mode, this should solve the booting
>problem. Does this seem like a sensible solution?
Is there a concern that a read-only mount of a corrupted non-root fs could cause
the system to panic/crash?

For booting, I think Warner is correct to suggest "print a warning and soldier on..".
However, once the system has booted (maybe only single user), I'd think it would
be better to fail the mount at least until an fsck is done on it than allow it to be
mounted read-only, unless there is no risk that doing this mount could cause a
crash/panic. Obviously, just my opinion given that I don't know UFS.

rick



More information about the freebsd-fs mailing list