Date: Tue, 03 May 2005 21:26:43 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby <ltning@anduin.net> To: <hartzell@alerce.com> Cc: "stable@freebsd.org" <stable@freebsd.org> Subject: Re: gmirror oddities Message-ID: <BE9D9D13.1488C%ltning@anduin.net> In-Reply-To: <17015.50206.651588.618737@satchel.alerce.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03-05-05 20:34, "George Hartzell" <hartzell@kestrel.alerce.com> wrote: >=20 > Eirik =D8verby writes: >> Hi! >>=20 >> I've been using gmirror for a while to safeguard my system disks. I have >> taken the slice-based mirror approach, where I use, say, ad0s1 and ad2s1= as >> providers. >> On one of my servers, this seems to be impossible. I create the mirror u= sing >> ad2s1 first (to keep my system running while I do some of the work), and >> then I re-initialize ad0s1 (making it exactly the size of ad2s1) before >> using gmirror insert to add it to the mirror. >> However, at this point - when doing a gmirror list - it turns out that i= t >> never added ad0s1 as a provider, but ad0 itself! As a result, I now have= a >> load of slices (ad0a, ad0b, ad0d, ad0e, ad0f) instead of having the same >> structure as I have on ad2s1. It's just like ad2s1, just without the "s1= " >> part. >>=20 >> I've tried "dd if=3D/dev/zero of=3D/dev/ad0 bs=3D65536" a couple of times, in = case >> some old provider metadata was stored there. I also have exactly the sam= e >> setup in another server, the only difference being that it behaves as >> expected.. >>=20 >> Am I doing something blatantly wrong here? This IS supposed to work, rig= ht? >> I've even found a very nice description of how to do it at >> http://people.freebsd.org/~rse/mirror/ >> confirming that what I'm doing is right. >>=20 >> I'm on 5.4-PRERELEASE, but this problem has been there since 5.3-p2 or >> something, which was when I first tried this. >=20 > I bet you're getting bitten by a problem that bit me. It's described > in the fine print in http://people.freebsd.org/~rse/mirror/. >=20 > Gmirror saves it's metadata on the last sector of its disk space. > Since the slice (adXs1) and the disk device (adX) end at the same > place on the disk, gmirror gets confused. It tastes devices in a > particular order, apparently devices first, then slices. It finds the > metadata when it tastes adX and goes ahead and uses it, even though it > should be associating it w/ adXsY. Hilarity ensues.... >=20 > The fix is described in the fourth comment block of Ralf's doc, either > make the slice a sector smaller than the disk device or hardcode the > provider name. I've been using the hardcoding approach, and it seems > to work for me. Same here, tried that immediately after my last post. Apologies for the noise ;) /Eirik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BE9D9D13.1488C%ltning>