Date: Sun, 25 Nov 2018 10:42:14 -0800 From: Kirk McKusick <mckusick@mckusick.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: "soralx@cydem.org" <soralx@cydem.org>, "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>, "Julian H. Stacey" <jhs@berklix.com>, Konstantin Belousov <kostikbel@gmail.com> Subject: Re: [bug] fsck refuses to repair damaged UFS using backup superblock Message-ID: <201811251842.wAPIgEpW053136@chez.mckusick.com> In-Reply-To: <YTOPR0101MB1162E62A2BA4D92D215C8983DDD60@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM>
index | next in thread | previous in thread | raw e-mail
> From: Rick Macklem <rmacklem@uoguelph.ca> > To: "soralx@cydem.org" <soralx@cydem.org>, > Kirk McKusick <mckusick@mckusick.com> > CC: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>, > "Julian H. Stacey" > <jhs@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? Kirk McKusickhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201811251842.wAPIgEpW053136>