From owner-freebsd-current@FreeBSD.ORG Mon Jul 13 11:12:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF01E1065A24 for ; Mon, 13 Jul 2009 11:12:03 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 5197E8FC0C for ; Mon, 13 Jul 2009 11:12:03 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n6DBC0aC065859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Jul 2009 13:12:01 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: From: Stefan Bethke To: ticso@cicely.de In-Reply-To: <20090711154724.GC76026@cicely7.cicely.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 13 Jul 2009 13:11:59 +0200 References: <7C636440-4F5D-47B0-BE20-D417B054B1F6@lassitu.de> <20090711133030.GA76026@cicely7.cicely.de> <2AAF9560-BD5C-4BB7-9AA6-D8F10853CF2D@lassitu.de> <20090711154724.GC76026@cicely7.cicely.de> X-Mailer: Apple Mail (2.935.3) Cc: FreeBSD Current Subject: Re: Unrecoverable UFS error but only with gmirror X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 13 Jul 2009 11:12:19 -0000 Am 11.07.2009 um 17:47 schrieb Bernd Walter: > On Sat, Jul 11, 2009 at 03:39:37PM +0200, Stefan Bethke wrote: >> Am 11.07.2009 um 15:30 schrieb Bernd Walter: >> >>> On Sat, Jul 11, 2009 at 02:54:01PM +0200, Stefan Bethke wrote: >>>> gmirror and/or ufs got into an odd state after a panic, where fsck >>>> could not fix errors on the mirror device, but each member >>>> filesystem >>>> was fine. Even after destroying the mirror, fixing all three >>>> member >>>> file systems with fsck, and recreating the mirror with just a >>>> single >>>> member fsck found the same errors on the mirror device. >>> >>> You've created the partitions without mirror? >>> The member drives are one block larger than the mirrored and if the >>> filesystem tries to use it under mirror it will fail. >>> The easiest way to avoid is to create the gmirror and then setup >>> your partitions on the mirror. >> >> No, I've newfs'ed the mirror device, not the disk partitions, so that >> shouldn't be the problem. Unless gmirror fails to subtract the >> metadata sector from the mirror device. > > I see - normally this should work fine then. > But you get read problem and I asume you wouldn't ask if you also see > hardware errors. > So this is likely accessing a block, which is not part of the volume. > Of course a bad UFS metadata can point to non existing data as well. > I would still verify the sizes - is the block far out of volume range, > or just a bit? > Is the underlying paritioning Ok? There must have been some misalignment, because the unreadable sector is in fact one past the last one: > CANNOT READ BLK: 8388576 > UNEXPECTED SOFT UPDATE INCONSISTENCY > > CONTINUE? yes > > THE FOLLOWING DISK SECTORS COULD NOT BE READ: 8388607, > # dd if=/dev/mirror/diesel_root bs=1m of=/dev/null > 4095+1 records in > 4095+1 records out > 4294966784 bytes transferred in 36.500572 secs (117668479 bytes/sec) $ expr 4294966784 / 512 8388607 It all looks like I did the newfs on the raw partition instead of on the mirror device, although I'm rather certain I did not, since I was aware of the metadata sector that gmirror requires, and was careful to create all partitions and filesystems accordingly. Any chance newfs would have rounded the device size the wrong way? Stefan -- Stefan Bethke Fon +49 151 14070811