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

Kirk McKusick mckusick at mckusick.com
Mon Nov 26 01:17:37 UTC 2018


> From: Rick Macklem <rmacklem at uoguelph.ca>
> To: Kirk McKusick <mckusick at mckusick.com>
> CC: "soralx at cydem.org" <soralx at cydem.org>,
>         "freebsd-fs at freebsd.org"
> 	<freebsd-fs at freebsd.org>,
>         "Julian H. Stacey" <jhs at berklix.com>,
>         Konstantin Belousov <kostikbel at gmail.com>
> Subject: Re: [bug] fsck refuses to repair damaged UFS using backup superblock
> Thread-Topic: [bug] fsck refuses to repair damaged UFS using backup superblock
> Date: Mon, 26 Nov 2018 00:07:36 +0000
> 
> Rick Macklem wrote:
> [stuff snipped]
> Ok, it looks like the FS_METACKHASH flag was meant to handle the
> old->new kernel transition. However, if I am reading the code
> correctly, it needs to be checked for sooner. Here's the code
> snippet (from sys/ufs/fdfs/ffs_vfsops.c):
> 
>       /* fetch the superblock and summary information */
> 812        if ((error = ffs_sbget(devvp, &fs, -1, M_UFSMNT, ffs_use_bread)) != 0)
> 813                goto out;
> 814        fs->fs_fmod = 0;
> 815        /* if we ran on a kernel without metadata check hashes, disable them */
> 816        if ((fs->fs_flags & FS_METACKHASH) == 0)
> 817                fs->fs_metackhash = 0;
> 
> I think ffs_sbget() calls readsuper() which calls calc_sbhash(),
> so lines 815-817 need to be near the top of readsuper(), I think?
> 
> rick
> [more stuff snipped]

Quite right. I have moved the metadata check to just before the
superblock check-hash is done (in sys/ufs/ffs/ffs_subr.c) as you
suggested (see -r340927).

I wanted to ensure that running a filesystem on an older kernel
would be detected. I coopted the FS_INDEXDIRS bit (which the kernel
has always cleared since UFS2 was first released) to be the
FS_METACKHASH flag. Thus if that flag is cleared, none of the
check-hashes can be trusted. But I failed to make that check
early enough to protect the reading of the superblock. Now fixed.

All kernels since the first check-hashes were added no longer
clear the FS_METACKHASH flag, but do clear any of the specific
hashes that they do not support so that it will continue to be
safe to move filesystems between kernels as the check hashes are
added. When fsck_ffs is run in manual (non-preen) mode, it checks
for missing check-hashes supported by the currently running kernel
and offers to add them.

	Kirk McKusick


More information about the freebsd-fs mailing list