From owner-freebsd-current@FreeBSD.ORG Thu May 8 14:45:37 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3BAD37B401 for ; Thu, 8 May 2003 14:45:37 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19C2843FAF for ; Thu, 8 May 2003 14:45:35 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from 12-234-22-23.client.attbi.com ([12.234.22.23]) by attbi.com (sccrmhc02) with SMTP id <2003050821453300200kusm4e>; Thu, 8 May 2003 21:45:34 +0000 Date: Thu, 8 May 2003 14:45:33 -0700 (PDT) From: Doug Barton To: Kirk McKusick In-Reply-To: <200305082047.h48KlDTh026805@beastie.mckusick.com> Message-ID: <20030508143459.C85154@12-234-22-23.pyvrag.nggov.pbz> References: <200305082047.h48KlDTh026805@beastie.mckusick.com> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Lukas Ertl Subject: Re: bin/51619 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 21:45:38 -0000 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