FreeBSD 5.3 and vinum upgrade #2

[Nikolaj Hansen]

On Sun, Dec 19, 2004 at 10:50:52AM +0100, Matthias Schuendehuette wrote:
> 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!

*Should* - Famous last words :-). The whole problem is, I cannot mount any 
thing without doing it this way. The reason for this is, as you pointed out
, that my disk setup is different than the norm:

$ sudo bsdlabel da1s1
Password:
# /dev/da1s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:   512000        0    4.2BSD     2048 16384 32008
  b:  1228535   512000      swap
  c: 17767827        0    unused        0     0         # "raw" part, don't edit
  h: 16027292  1740535     vinum

Both sides of the mirror are made like this.

Of cause I _really_ want to keep the data on the disks. Is there an easy way to fix
the disks for geom_vinum compability, or do they need to be rebuilt from the ground up?

I suppose one way of doing it is to fix one side of the mirror, copy the data, fix the
second side of the mirror, copy the data? This will then have to be done through the
respektive vinum version.

Thank God I have not made the root patition a vinum one ..

The second option is to back everything up to a file on the data disks, nuke the mirror
to the new setup and then restore.

> 
> 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)

Yes, I realize that, but for now the volumes are all marked stale inspecting the drives etc. through
the new geom_vinum, and the setstate command
returns "Bad Address" when you try to use it in the new geom_vinum. Not very informative.

> 
> 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...).

Exactly the error I have been struggeling with as well. Using a late load of the old
vinum driver makes it possible for me to manually boot the system by hand as suggested.

> 
> 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 ...

I see the advantages of this - the disk setup on the old patitions could be
a bit tricky.

> 
> > 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
> 

-- 

With regards / med venlig hilsen

Nikolaj Hansen
Algade 15, 2 tv
9000  Aalborg
Danmark

"Even on the highest throne in the world, we are seated, still, upon our
arses." - Montaigne