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. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
