On Mon, 25 Nov 2002, Kirk McKusick wrote:
> Date: Mon, 25 Nov 2002 01:08:30 -0800 (PST) > From: Julian Elischer <[EMAIL PROTECTED]> > To: Kirk McKusick <[EMAIL PROTECTED]> > cc: [EMAIL PROTECTED], Robert Watson <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > Subject: Re: Update to UFS2 Superblock Format > In-Reply-To: <[EMAIL PROTECTED]> > X-ASK-Info: Whitelist match > > On Sun, 24 Nov 2002, Kirk McKusick wrote: > > > Some of these fields could usefully be made unsigned others not > > (for example fs_pendingblocks and fs_pendinginodes). So just > > going through and making everything unsigned is not the right > > approach. I will make a pass through and consider changing some > > of these fields once the tree opens back up, but not at this > > point in time when we are trying to keep changes to a minimum > > and do not have time for extensive testing. > > > > Kirk McKusick > > I'm not in a hurry.. It's just something that I thought should be > considered..... "eventually". > > BTW how can fs_pendingblocks and fs_pendinginodes be -ve? > > In theory they should never go negative. But if an inconsistency > occurs (for example a crash and remount before background fsck > has run) the accounting can get out of whack and the numbers go > negative. We check for this happening and take corrective action. > If they were changed to unsigned, we would miss the negative > transition and instead suddenly think that we had a huge amount > of pending space to free. So this is an example where changing > them to unsigned would break existing code. But that is no worse than the case where the drive as been whacked and you get a huge +ve number.. You have to check for that anyhow if you are checking for bad values. Checking for -ve numbers is only half of the story. If you are checking for impossibly large +ve numbers then you catch those that would have been -ve. So, Who catches the -ve transition anyway? We found the problem with the rotors because they are -ve, leading into an array offset backwards into hyperspace. It's not efficient to test every offset every time it's used. Checking for -ve is no harder than checking for (say), being greater than the number of blocks in a cylinder group. > > Kirk McKusick > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message