From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 19:38:28 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0608D16A4CE for ; Fri, 12 Nov 2004 19:38:28 +0000 (GMT) Received: from deskaheh.nysindy.org (host-69-48-73-242.roc.choiceone.net [69.48.73.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39C6643D5C for ; Fri, 12 Nov 2004 19:38:27 +0000 (GMT) (envelope-from ski@indymedia.org) Received: from wjb.mm (unknown [10.0.0.254]) by deskaheh.nysindy.org (Postfix) with ESMTP id 6EBD441A05; Fri, 12 Nov 2004 14:38:24 -0500 (EST) Received: from 12.170.146.195 (SquirrelMail authenticated user ski); by wuhjuhbuh.afraid.org with HTTP; Fri, 12 Nov 2004 14:38:25 -0500 (EST) Message-ID: <50520.12.170.146.195.1100288305.squirrel@12.170.146.195> In-Reply-To: <20041112062244.GH635@pcwin002.win.tue.nl> References: <1995.10.0.0.26.1100231050.squirrel@10.0.0.26> <20041112062244.GH635@pcwin002.win.tue.nl> Date: Fri, 12 Nov 2004 14:38:25 -0500 (EST) From: "Brian Szymanski" To: "Stijn Hoop" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-stable@freebsd.org Subject: ad0 vs. ad0s1 (was Re: vinum troubles on 5.3) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 19:38:28 -0000 > That's strange. What is the output of > > fdisk ad0 > bsdlabel ad0s1 > > Maybe something in GEOM gets confused... > > If the disappearing device node problem is fixed, gvinum should work in > this case. -bash-2.05b# bsdlabel ad0 # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] b: 2097152 0 swap c: 80292807 0 unused 0 0 # "raw" part, don't edit e: 40146404 40146403 vinum f: 38049248 2097153 vinum -bash-2.05b# bsdlabel ad0s1 # /dev/ad0: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 40140800 40146668 4.2BSD 0 0 0 b: 2097152 0 swap c: 80293248 0 unused 0 0 # "raw" part, don't edit e: 40146404 40146403 vinum f: 38049248 2097153 vinum [ I omitted fdisk output because it's very verbose - it's just a standard everything on the drive is freebsd type 165 dealie. ] When I tell bsdlabel to look at ad0, it doesn't see partition a. But when looking at ad0s1, it does. So I just told bsdlabel to add slice a on ad0s1 and things seem peachy keen (bsdlabel -e ad0s1) - I can't verify that this solves the (g)vinum problem since I need to get in to the bios to change boot settings and can't do that remotely. So that begs the question, what is the difference between ad0 and ad0s1 to these utilities, and what *should* it be? And, where on earth is the disklabel for "ad0" being saved, if not in ad0s1? Is it possibly overwriting something important, e.g. in the bootstrap code, which could explain the reason I was getting "not ufs" when I tried to boot with vinum? Other less relevant follow-ups below, thanks to all who helped: > A root mirrored configuration isn't that straightforward, imo :) But it > should work. It seemed straightforward on 4.x :-) >> Using vinum, I lose state information for the drive on ad2 after reboot - >> M2 is shown in "vinum l" output only as "referenced"... > > That is to be expected, as you discovered below... Why is this to be expected, because of gvinum? >> I originally was trying a complex configuration like so: >> drive A 200G >> drive B 200G >> drive C 100G >> drive D 100G >> >> I set the concat of drive all of drives C+D to be a volume makeshift, and >> added drive definition like so: >> drive MS /dev/gvinum/makeshift >> > Then, the idea was to do a raid5 of drives A, B, and "drive" MS. > I don't know if this is even possible. It's an interesting idea but even if it > works, recovery is totally non-trivial when either drive C or drive D goes > away. Plus, you'll surely take a huge performance hit because of the two vinum > layers you have to go through for every single access. Recovery is trivial when drive C or D goes. Since drives C and D form one raid-5 volume together, just chuck both drives and replace the makeshift drive with a new 200G drive. I am aware of and don't care about the performance hit. Cheers, Brian Szymanski ski@indymedia.org