Date: Fri, 12 Nov 2004 07:22:44 +0100 From: Stijn Hoop <stijn@win.tue.nl> To: Brian Szymanski <ski@indymedia.org> Cc: freebsd-stable@freebsd.org Subject: Re: vinum troubles on 5.3 Message-ID: <20041112062244.GH635@pcwin002.win.tue.nl> In-Reply-To: <1995.10.0.0.26.1100231050.squirrel@10.0.0.26> References: <1995.10.0.0.26.1100231050.squirrel@10.0.0.26>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041112062244.GH635>