From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 20 18:02:31 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4954416A4CF for ; Tue, 20 Jul 2004 18:02:31 +0000 (GMT) Received: from angryfist.fasttrackmonkey.com (angryfist.fasttrackmonkey.com [216.223.196.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C889B43D46 for ; Tue, 20 Jul 2004 18:02:30 +0000 (GMT) (envelope-from spork@fasttrackmonkey.com) Received: (qmail 64488 invoked by uid 2003); 20 Jul 2004 18:01:11 -0000 Received: from spork@fasttrackmonkey.com by angryfist.fasttrackmonkey.com by uid 1001 with qmail-scanner-1.20 (clamscan: 0.65. Clear:RC:1(216.220.116.154):. Processed in 0.043998 secs); 20 Jul 2004 18:01:11 -0000 Received: from unknown (HELO toad.nat.fasttrackmonkey.com) (216.220.116.154) by 0 with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Jul 2004 18:01:10 -0000 Date: Tue, 20 Jul 2004 14:01:06 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@toad.nat.fasttrackmonkey.com To: Peter Jeremy In-Reply-To: <20040720092848.GD3001@cirb503493.alcatel.com.au> Message-ID: <20040720135157.Q28049@toad.nat.fasttrackmonkey.com> References: <20040719191408.V28049@toad.nat.fasttrackmonkey.com> <20040720021432.O28049@toad.nat.fasttrackmonkey.com> <20040720092848.GD3001@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: disk recovery help X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2004 18:02:31 -0000 On Tue, 20 Jul 2004, Peter Jeremy wrote: > It's difficult to see how a sanely written RAID utility could totally > screw up an array in a short time - a 'build' utility presumably > writes known data to the array but logically it would do so > sequentially. The only thing I can think of is that the controller > had a significant amount of cached data - which has been wiped, rather > than written back to the disk. This is one case where I'd like to see a "Are you sure (y/n)?" prompt. In the future, I'm sticking with the adaptec BIOS to do a drive replace/rebuild. Adaptec's raidutil is just a bit too easy to shoot yourself in the foot with. I have a call in to adaptec about this, they are having a hard time telling me just what the "build" (not "rebuild") command does, but they are fairly certain that it writes it's config at the end of the disk, then zeros it from the outside in. > If you haven't run newfs and have the correct disklabel, the disk > should be in a reasonably sane state. Have you tried running something > like ports/sysutils/scan_ffs over the disk (or your copy of it)? I don't have the actual disk; we're very short on any sort of spare hardware so we had to newfs the partition in question and start over. I grabbed the dd "image" before that. An fsck on the problem partition ran for 12 hours and I don't know how far along it was. I looked at scan_ffs just now, and it looks like it works on the whole disk trying to find the label. Since I only have one partition, there's no label. > Have you tried dumping vn0c? I could try that, but I'd have to find myself another 26GB of space somewhere. Thanks! Charles > -- > Peter Jeremy >