Date: Sun, 19 Dec 2004 10:50:52 +0100 From: Matthias Schuendehuette <msch@snafu.de> To: freebsd-stable@freebsd.org Cc: Nikolaj Hansen <nikolaj.hansen@barnabas.dk> Subject: Re: FreeBSD 5.3 and vinum upgrade #2 Message-ID: <200412191050.52445.msch@snafu.de> In-Reply-To: <20041219061221.GA977@sauron.barnabas.dk> References: <41C48A6F.7000203@barnabas.dk> <1103416078.6339.4.camel@zappa.Chelsea-Ct.Org> <20041219061221.GA977@sauron.barnabas.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200412191050.52445.msch>