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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 super= block > 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 McKusick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201811251842.wAPIgEpW053136>