Subject: Re: ffs compatibility added, fsck may complain
To: Perry E. Metzger <perry@piermont.com>
From: Darrin B. Jewell <dbj@netbsd.org>
List: current-users
Date: 01/11/2004 23:48:33
"Perry E. Metzger" <perry@piermont.com> writes:

> "Darrin B. Jewell" <dbj@netbsd.org> writes:
> > I added the following to src/UPDATING
> >
> > 20040109:
> >         Compatibility for old ffs superblock layouts has been
> >         added, and the restrictive fsck checks have been reenabled
> >         when using those layouts.  If you have been using -current
> >         since 20030402, you may find that fsck again signals fatal
> >         superblock mismatches.  To work around, you can use
> >         fsck -b 32 to restore an alternate superblock.
> 
> Actually, it is fsck_ffs. I just found that out the hard way hitting
> my head against the wall because fsck doesn't have an -b option.

Yes, you are correct.  I should have said fsck_ffs, and I will
fix the UPDATING file.

> 
> Also, the situation is REALLY unfortunate. It means that you're going
> to end up with machines mysteriously failing on people without much
> recourse in the field if you don't happen to remember the cure. Also,
> people needing to blind upgrade boxes in colos will get screwed -- I'm
> one of those.

This should only affect people who migrated from a kernel before
20030402 directly to a kernel from the time period
between 20030913 (revision 1.120 of ffs_vfsops.c)
and my changes of 20040109 (revision 1.131 of ffs_vfsops.c)

During the time period 20030913 and 2040109, the kernel would
partially upgrade the superblock, but carefully clear the
FS_FLAGS_UPDATED bit.  People who upgraded in that time period also
needed to manually upgrade their fsck before trying to run it or else
they would run into the exact same problem.

During the time period of 20030402 to 20030913, the kernel
would set the FS_FLAGS_UPDATED bit and then fsck doesn't have
this problem. (but the filesystem is then incompatible with 1.6.x)

[side note:
Also mind a different bug that was introduced into the kernel
which will cause you problems if you allowed a kernel from between
20030913 (revision 1.120 of ffs_vfsops.c) and 20030929 (revision
1.35 of fs.h) to upgrade your superblock.
Those problems could lie latent for years until you upgrade to a
kernel that uses a previously unused fs_flags bit.  See
  http://mail-index.netbsd.org/tech-kern/2003/09/28/0003.html
and
  http://mail-index.netbsd.org/tech-kern/2003/10/07/0005.html
]

If you run -current and don't follow -current upgrade issues,
you should expect to lose.  Before my fixes, the lossage would
have occured for people upgrading from 1.6.x.

> 
> Is there any way to either get the kernel to fix this for you during
> boot, or to provide a way to fix it in advance so that fsck doesn't
> fail during reboot? This is actually pretty important.

Yes, there is probably a workaround for this, which would be to
check to see if
  (((fs->fs_old_flags & FS_FLAGS_UPDATED) == 0) &&
    (fs_maxbsize == fs_bsize))
and if so, then force a full upgrade or at least have fsck_ffs
do the relaxed superblock comparison.  I could put something
to handle this case in the kernel temporarily or in fsck_ffs,
but I don't really want to spend the time to test this and ensure
that i don't create new problems or perpetuate the existence
of hidden screwy incompatible superblocks.

Basically, compatibility accross the ffs upgrade was botched,
and botched several times.  I've done my best to avoid ongoing
problems, but I don't want to get into providing compatibilty
for all the intermediate kernel versions that would screw
around with your filesystem in their own unique losing ways.

Darrin

> 
> Perry
> 
> >
> > See the following message to tech-kern
> >  <URL:http://mail-index.netbsd.org/tech-kern/2004/01/05/0011.html>
> >
> > or pr's port-macppc/23925 and port-macppc/23926 for more details
> >
> > See pr 23925 or 23926 for more details
> >  <URL:http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=23925>
> >  <URL:http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=23926>
> >
> 
> -- 
> Perry E. Metzger		perry@piermont.com