ad0 vs. ad0s1 (was Re: vinum troubles on 5.3)

[Brian Szymanski]

> 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 at indymedia.org