Garance A Drosihn wrote:
> At 7:18 PM +0000 7/29/02, [EMAIL PROTECTED] wrote:
> >I cvsup'd on Friday of last week, after I restored /usr. Did
> >the fix come later than that? I'm kind of afraid to try it
> >again :) Thanks, Rob.
> The fix in question was to -stable, not -current (I am not sure
> if that was mentioned earlier). I think the change was committed
> to -stable sometime in early July, iirc.
It really annoyed the hell out of me that this was characterized
as a "bug" in the older version of fsck being run.
Specifically, there is "care" and "don't care" data in the
superblocks, and the first and second superblocks are expected
to match. The "don't care" is hard-coded in the fsck program
version itself, and it's not simple to add more "don't care"
data on future revisions. It's tantamount to software handling
shared library incompatabilities without version numbers.
The FFS in -current extends its use of the superblock, so that
there are some additional fields. When these are seen to be
non-zero by fsck, the comparison fails.
Probably the canonically correct thing to do would be to divide
the available free space into two ranges, one which you care
about changing on down-versions, and one which you don't, with
the data in this case being in the region you don't care about
(alternately, part of the space could be allocated for a bitmap
of 32 bit regions that you do/don't care about changing).
Basically, the problem is that the new additions to -current
don't technicallly matter to -stable, but do matter in the
sense of the compare being made.
The "fix" is to modify -stable to ignore these changes.
The -current code doesn't seem to mind the data not being
carried forward in the secondary, etc. superblocks, so one
has to really question why the data needs t be stored on
disk at all for this.
The real answer is that the data layout of the FFS has been
changed, so you need a new fsck for -stable for interoperability
so that the changed ranges will be ignored by fsck.
Note that this is **NOT A BUG** in your -stable fsck, it is
a **PROCESS BUG IN FREEBSD**. It's **NOT POSSIBLE** for a
program to **GROW A BUG**. The underlying FFS data format
changed under you. If there is any bug, it's in the basic
assumption that, if you follow -current, that you will also
keep your -stable up to date, if you share disks between them.
This is not an unreasonable assumption, but it sure as heck
should have been more explicitly noted than it was.
One thing that would make this easier, if the zoning approach
were impossible (without a bitmap, it must be impossible,
since it pre-reserves too large a range for non-dependent
metadata changes) would be a freaking version number bump,
and a much nicer message from fsck when it sees a version
mismatch, rather than it losing its cookies.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message