From owner-freebsd-stable@FreeBSD.ORG Fri Nov 12 06:22:47 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 C34F916A4CE for ; Fri, 12 Nov 2004 06:22:47 +0000 (GMT) Received: from pastinakel.tue.nl (pastinakel.tue.nl [131.155.2.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14D1743D1F for ; Fri, 12 Nov 2004 06:22:47 +0000 (GMT) (envelope-from stijn@pcwin002.win.tue.nl) Received: by pastinakel.tue.nl (Postfix, from userid 40) id 79A1D14BBDF; Fri, 12 Nov 2004 07:22:46 +0100 (CET) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by pastinakel.tue.nl (Postfix) with ESMTP id 4F13D14BB44; Fri, 12 Nov 2004 07:22:45 +0100 (CET) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.13.1/8.13.1/Submit) id iAC6MjGS013584; Fri, 12 Nov 2004 07:22:45 +0100 (CET) (envelope-from stijn) Date: Fri, 12 Nov 2004 07:22:44 +0100 From: Stijn Hoop To: Brian Szymanski Message-ID: <20041112062244.GH635@pcwin002.win.tue.nl> References: <1995.10.0.0.26.1100231050.squirrel@10.0.0.26> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6v9BRtpmy+umdQlo" Content-Disposition: inline In-Reply-To: <1995.10.0.0.26.1100231050.squirrel@10.0.0.26> User-Agent: Mutt/1.4.2.1i X-Bright-Idea: Let's abolish HTML mail! X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mailhost.tue.nl X-Spam-DCC: : X-Spam-Status: No, hits=-4.9 required=6.3 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Level: cc: freebsd-stable@freebsd.org Subject: 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 06:22:48 -0000 --6v9BRtpmy+umdQlo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Nov 11, 2004 at 10:44:10PM -0500, Brian Szymanski wrote: > After a long and happy time with vinum under 4.8 -> 4.10, I'm finding > things very broken in 5.3. The config I'm trying to accomplish is > relatively simple, just a root mirrored volume configuration which worked > under 4.x. A root mirrored configuration isn't that straightforward, imo :) But it should work. > 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... > Browsing some mailing lists I found that gvinum is the way to go these > days, so I changed to using geom_vinum/gvinum, and the information is > retained across boot, but when I try to boot to the root volume, it says > that the drive is not UFS. When I boot on another partition to look at the > situation, I found that there were no entries in /dev for /dev/ad0s1a. I > wanted to create a ad0s1a entry with mknod, but of course we've got devfs > now, so that didn't work. I'm stumped and not sure how to proceed. Any > ideas? 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. > I originally was trying a complex configuration like so: > drive A 200G > drive B 200G > drive C 100G > drive D 100G >=20 > 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 >=20 > 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 vi= num layers you have to go through for every single access. RAID-5 is normally used when you need redundancy but can't afford to shell = out the cash for mirroring. If you don't care about loss of data you are better off using stripe, if you are absolutely paranoid about your data you are better off mirroring [1]. If you do need RAID-5 though, you have to do it properly, which means evenly-sized disks. Do make sure they're not all from the same manufacturing batch also... =20 > Unfortunately this caused a panic, which is less surprising. Does anyone > know of another way to accomplish the same thing (Raid5 over two disks and > 2 half sized disks concatenated together?) or a similar result? The best you can do is have 100G of drives A & B participate in a 4 x 100G RAID-5, then use the other 2 x 100G in a separate volume. You *could* theoretically concat 2 plexes in one volume, where one plex is RAID-5 and t= he other mirror or some such, but as said above, it's not easy to recover from= a drive failure in that case, defeating the point of RAID imho. HTH, --Stijn [1] all my opinion; there are lots of opinions on what type of RAID is best in what situation. My point is mainly that you really need to consider what you are trying to accomplish by using RAID. --=20 "Linux has many different distributions, meaning that you can probably find one that is exactly what you want (I even found one that looked like a Unix system)." -- Mike Meyer, from a posting at questions@freebsd.org --6v9BRtpmy+umdQlo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBlFa0Y3r/tLQmfWcRArIfAJ4yahrvdwZ0ar4bc3huJQcOxLrtRwCgmj8y yIAZtKAXWtbFIpK1gTP+UQM= =aZQz -----END PGP SIGNATURE----- --6v9BRtpmy+umdQlo--