FreeBSD 5.3 and vinum upgrade #2

[Matthias Schuendehuette]

Am Sonntag, 19. Dezember 2004 07:12 schrieb Nikolaj Hansen:
> I gave the 5.3 upgrade another swing. Now the situation is:
>
> $ uname -a
> FreeBSD sauron.barnabas.dk 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Sat
> Dec 18 18:39:09 CET 2004    
> root at sauron.barnabas.dk:/usr/obj/usr/src/sys/KERNEL_5_3  i386

Perhaps you better upgrade to RELENG_5 (5.3-STABLE). I'm not aware of 
any reasons against that in the moment and, besides others, gvinum was 
improoved since 5.3-RELEASE. But that's your decision...

> I think I am understanding a little more of this now. In order to use
> my scsi / ATA setup, I need to use the geom_vinum.ko *and* the
> vinum.ko modules?

Oh no! Don't do that!

If you switch to the new geom_vinum, all you *should* need is:

geom_vinum_load="YES"	in /boot/loader.conf

Please comment out (or remove) the vinum*-lines in loader.conf!

Additionally you have to change all the entries in /etc/fstab to

/dev/gvinum/<volume_name>  /<mount_point> ....
(Note the *g*vinum in the device path)

But for the first test, you better comment out these lines and try to 
mount the volumes manually...

> [...]
> Is this correct? I suppose the ATA drives should be mounted on the
> new /dev/gvinum/* and the scsi drives on the /dev/vinum/*? 

No! As stated above, *all* should now be handled by geom_vinum.

> [...]
> As I wrote earlier the above loader.conf is not working. If I leave
> out the load of the old vinum driver it does not seem to be possible
> to mount the scsi drives. If I leave out the geom_vinum a mount of a
> drive causes a kernel panic.

You *can* use the old "classic" vinum, but it only works if you start 
classic-vinum *after* the system has come up. You cannot start 
classic-vinum at boottime with loader.conf, at least it doesn't work 
for me ('dangling vnode'-panic...).

Before you switch to geom_vinum, you should check your partitions as 
already mentioned in an earlier mail...

Try a 'bsdlabel /dev/da1s1' and see, if your vinum-partition does *not* 
start at an offset of 0.

On my disk, it looks as follows:

8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:  4226709       16     vinum
  c:  4226725        0    unused        0     0         # "raw" part...

So here the vinum partition starts at an offset of 16 and therefor is 16 
blocks smaller than the whole disk ('c'-partition). That's ok.


If it *would* read like that:

8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:  4226725        0     vinum
  c:  4226725        0    unused        0     0         # "raw" part...

it would not work with geom_vinum!

The background is, that with geom_vinum you don't need any 
vinum-partitions any more, further it is possible to use the whole disk 
(or slice) *without* any BSD partitions. But in the latter case above 
(with 0-offset), geom_vinum can't distinguish between the whole slice 
and the 'a'-partition. This did lead to an error (I did not try this 
with a recent geom_vinum). Anyway, you better spend these 16 blocks 
offset to be sure IMHO ...

> It would be nice if any of you would comment on the above config.

I hope it's a bit more clear now...

> Perhaps I am ignorant, but it seems to me it would have been easier
> to make the regular vinum diver handle geom drives in place of making
> a new kernel object? Or perhaps theres a technical reason for not
> doing so?

Exactly that's the case. If you have to use a completly different 
infrastructure below, it's obviously more easy to start from scratch...
-- 
Ciao/BSD - Matthias

Matthias Schuendehuette	<msch [at] snafu.de>, Berlin (Germany)
PGP-Key at <pgp.mit.edu> and <wwwkeys.de.pgp.net> ID: 0xDDFB0A5F