Date: Thu, 8 May 2003 14:45:33 -0700 (PDT) From: Doug Barton <DougB@FreeBSD.org> To: Kirk McKusick <mckusick@beastie.mckusick.com> Cc: Lukas Ertl <l.ertl@univie.ac.at> Subject: Re: bin/51619 Message-ID: <20030508143459.C85154@12-234-22-23.pyvrag.nggov.pbz> In-Reply-To: <200305082047.h48KlDTh026805@beastie.mckusick.com> References: <200305082047.h48KlDTh026805@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 8 May 2003, Kirk McKusick wrote:
> The first UFS1 alternate is 32
> sectors (16K) in from the beginning of the disk. That alternate
> also remains untouched by UFS2. So, someone manually running
> fsck will be given the opportunity to look for alternate
> superblocks and will find that one and *still* end up messing
> up the filesystem.
Please forgive me if my ignorance about how this stuff actually works
makes this a foolish question, but it occurs to me that part of the
problem may be related to the fast newfs code for ufs2. In case I haven't
been clear, I did actually do this fs ufs1 first, then re-did it in ufs2.
While not a lot of our users will be doing what I did _next_ in terms of
running a 4.x fsck binary against that ufs2 file system, I think that a
lot of users will be converting existing ufs1 slices to ufs2.
So, what if we pushed the problem of finding and deleting ufs1 alternate
superblocks down to the ufs2 newfs code? That way, there is no possibility
of getting boned by a releng_4 fsck, since it won't find _anything_ that
it thinks it understands, and will just give up trying, instead of trying,
and doing the wrong thing.
Am I totally off base here?
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030508143459.C85154>