Date: Sat, 22 Jun 2002 07:49:17 -0700 (PDT)
        From: David Wolfskill <[EMAIL PROTECTED]>
        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.)

        David H. Wolfskill                              [EMAIL PROTECTED]
        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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to