From owner-freebsd-current@FreeBSD.ORG Thu May 8 15:00:54 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 B110437B401; Thu, 8 May 2003 15:00:54 -0700 (PDT) Received: from mailbox.univie.ac.at (mailbox.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53AA743F3F; Thu, 8 May 2003 15:00:53 -0700 (PDT) (envelope-from l.ertl@univie.ac.at) Received: from [10.0.0.2] (adslle.cc.univie.ac.at [131.130.102.11]) by mailbox.univie.ac.at (8.12.2/8.12.2) with ESMTP id h48M0eRx026244; Fri, 9 May 2003 00:00:43 +0200 Date: Fri, 9 May 2003 00:00:35 +0200 (CEST) From: Lukas Ertl To: Doug Barton In-Reply-To: <20030508143459.C85154@12-234-22-23.pyvrag.nggov.pbz> Message-ID: <20030508234803.O592@korben.in.tern> References: <200305082047.h48KlDTh026805@beastie.mckusick.com> <20030508143459.C85154@12-234-22-23.pyvrag.nggov.pbz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-DCC-ZID-Univie-Metrics: mailbox 4251; Body=3 Fuz1=3 Fuz2=3 cc: freebsd-current@freebsd.org cc: Kirk McKusick 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 22:00:55 -0000 On Thu, 8 May 2003, Doug Barton wrote: > 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. Yes, and that is exactly what leads to the problem. If you would put a UFS2 fs on a blank, virgin disk, everything is ok (except the possibility that some random magnetic forces accidentally create a UFS1 magic cookie at the old UFS1 superblock location :-) ). > 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. I think so, too. And it will affect every 4.x binary that tries to do anything with the superblock (like mounting etc.). Given the possibility that some users might dual boot 4.x/5.x it's not a very constructed scenario we have here. > 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 possibilit= y > 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? No, you're very right, and this is actually what I'm trying to accomplish with my humble patches :-) regards, le --=20 Lukas Ertl eMail: l.ertl@univie.ac.at UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 der Universit=E4t Wien http://mailbox.univie.ac.at/~le/