Date: Sat, 22 Jun 2002 12:37:04 -0700 From: Kirk McKusick <mckusick@beastie.mckusick.com> To: current@freebsd.org Cc: Poul-Henning Kamp <phk@critter.freebsd.dk> Subject: Re: you should probably track current@ these days... Message-ID: <200206221937.g5MJb4n9024400@beastie.mckusick.com> In-Reply-To: Your message of "Sat, 22 Jun 2002 20:58:28 %2B0200." <26402.1024772308@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Date: Sat, 22 Jun 2002 07:49:17 -0700 (PDT)
From: David Wolfskill <david@catwhisker.org>
To: mckusick@freebsd.org, phk@freebsd.org
Subject: UFS2, superblocks, and UFS compatability
I had noted phk's message about Kirk's "commitatron" being
readied for action; I was, however, slightly surprised by
some of the results of yesterday's (daily) build of -CURRENT.
I had expected (and a quick, ex post facto, look at Kirk's
commit message confirms) that the intent was to maintain
compatability with UFS1.
What surprised me was that after building yesterday's
-CURRENT successfully (actually, without incident at all),
I poked around a bit, then re-booted to -STABLE. (I'm
tracking both -STABLE and -CURRENT on the same physical
disk, using different slices. Although I build -CURRENT
daily, and do some "reality checks," I still do the bulk
of the work with the machines in question -- such as anything
that updates the CVS repository -- in -STABLE. This probably
reflects a rather conservative nature on my part.) The
"surprise" was that -STABLE's fsck was rather expressively
unhappy about the file systems that had been mounted while
running -CURRENT.
In particular, STABLE's fsck claimed that the superblock
for each such file system was corrupt.
I found (empirically) that running fsck (and allowing it
to recover the superblock from the backup superblock at 32)
for each of these files systems, then rebooting, made STABLE
much less unhappy. :-}
The -CURRENT code appears to be able to use a UFS1 file
system OK -- I was able to boot back to -CURRENT again in
preparation for building today's -CURRENT -- but it appears
to me (and I haven't looked at the code to verify this)
that something in the superblock is getting updated in a
way that isn't completely compatable with UFS1, at least
if the file system is updated.
If this is intended, mention of it in UPDATING might be
useful. If it's not, I'll be happy to help narrow down
where things go awry and test the results of (proposed)
patches. (Whether they are patches to -CURRENT, -STABLE,
or both.)
Cheers,
david
--
David H. Wolfskill david@catwhisker.org
Trying to support or use Microsoft products makes about as much sense
as painting the outside of a house with watercolors.
My hope was that you would be able to switch painlessly between
new and old systems. To make this work, I made a change to fsck
on April 7th:
RCS file: /usr/ncvs/src/sbin/fsck_ffs/setup.c,v:
revision 1.30
date: 2002/04/07 05:16:33; author: mckusick; state: Exp; lines: +25 -61
When checking the alternate superblock, we used to copy any fields
that might have changed, then did a byte-by-byte comparison with
the alternate. If any unused fields got used, they had to be added
to the exception list. Such changes caused too many false alarms.
So, I have changed the comparison algorithm to compare a selected
set of fields that are not expected to change. This new algorithm
causes far fewer false hits and still does a good job of detecting
problems when they have really occurred. In particular, this change
should ease the transition to kernels supporting UFS2 which make
some significant changes to the superblock.
Sponsored by: DARPA, NAI Labs
This was supposed to get MFC'ed back to 4.X, though I am not sure if
that ever happened. Because of the breakup of fsck into fsck and fsck_ffs
I am not sure how one goes back and makes changes to whet used to be
fsck/setup.c. Anyway, if your fsck_ffs is running with a copy of setup.c
that predates this change, then it will bitch about the superblock being
corrupted and recover by using the first alternate. You can avoid the
bitching by using `fsck -b16 ...' to override the integrity check.
Given that you have had the problem, I expect that others will as well,
so I will make a note in the UPDATING notes to suggest the use of
`fsck -b16 ...' when going back to using filesystems on 4.X systems.
Kirk McKusick
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206221937.g5MJb4n9024400>