Date: Wed, 7 May 2003 22:56:36 -0700 (PDT) From: Doug Barton <DougB@FreeBSD.org> To: Kirk McKusick <mckusick@McKusick.COM> Cc: Lukas Ertl <l.ertl@univie.ac.at> Subject: Re: bin/51619 Message-ID: <20030507225300.P9851@znfgre.qbhto.arg> In-Reply-To: <200305072229.h47MTDTh024656@beastie.mckusick.com> References: <200305072229.h47MTDTh024656@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 May 2003, Kirk McKusick wrote:
> At one time I had the suggested change that you made in bin/51619
> in the FreeBSD-5.0 newfs program. The problem with that change is
> that the bootstrap on some architectures now exceeds 8K which means
> that instead of zeroing an old superblock you destroy the boot code.
> So, I removed the zeroing of the old UFS1 superblock area. A possible
> alternative would be to check for a UFS1 magic number at the old
> location (and also at the 16K first backup location) and zero out
> just those fields if they are found. While it is possible that a
> bootstrap might just have that number at that offset, it is highly
> unlikely.
Thanks for the historical perspective. I am not sure how big of a problem
my situation is, since it will only apply to people trying to run a
releng_4 fsck on a ufs2 filesystem under the special circumstances you
described. However, if it's something we can prevent with relative ease, I
think it's worthwhile to do so. No sense loading the foot-shooting gun
with more bullets than absolutely necessary.
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030507225300.P9851>