Date: Tue, 26 Nov 2002 00:03:47 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Kirk McKusick <mckusick@beastie.mckusick.com> Cc: current@freebsd.org, Robert Watson <rwatson@tislabs.com>, re@freebsd.org Subject: Re: Update to UFS2 Superblock Format Message-ID: <Pine.BSF.4.21.0211252349400.46897-100000@InterJet.elischer.org> In-Reply-To: <200211260714.gAQ7E059070465@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 25 Nov 2002, Kirk McKusick wrote: > Date: Mon, 25 Nov 2002 01:08:30 -0800 (PST) > From: Julian Elischer <julian@elischer.org> > To: Kirk McKusick <mckusick@beastie.mckusick.com> > cc: current@freebsd.org, Robert Watson <rwatson@tislabs.com>, > re@freebsd.org > Subject: Re: Update to UFS2 Superblock Format > In-Reply-To: <200211250619.gAP6J059068226@beastie.mckusick.com> > 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 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?Pine.BSF.4.21.0211252349400.46897-100000>