Re: geom_vinum problems (crashes and lockups)

From: Paul Mather <paul_at_gromit.dlib.vt.edu>
Date: Sat, 26 Jun 2004 15:54:50 -0400
On Sat, 26 Jun 2004 15:03:15 +0200, Stijn Hoop <stijn_at_win.tue.nl> wrote:

> On Sat, Jun 26, 2004 at 02:07:03PM +0200, Lukas Ertl wrote:
> > On Thu, 24 Jun 2004, Daryl Chance wrote:
> > > for /dev/ad4s1:
> > > mp3# bsdlabel /dev/ad4s1
> > > # /dev/ad4s1:
> > > 8 partitions:
> > > #        size   offset    fstype   [fsize bsize bps/cpg]
> > >  c: 60074784        0    unused        0     0
> > >  d: 60074784        0    4.2BSD     2048 16384 28512
> > 
> > This is a situation that I currently consider 'unsupported'.  The problem 
> > is that the 'd' partition has no offset, thus it is (from the point of 
> > view of a geom_vinum drive geom) the same as the 'c' partition.  This is 
> > the first problem.
> 
> [snip]
> 
> > I'm not sure if I find a proper hack for this, so, for now, this is an 
> > unsupported configuration.  This means that the partition where you want 
> > to put a vinum drive on _must not_ start at the beginning of a drive and 
> > has to have an offset, i.e. 16 sectors, as a standard label from 'bsdlabel 
> > -w' has.
> 
> Hum, is/was this documented somewhere? I just set up two RAID-5's on
> -STABLE, and I have done this every time I did a RAID setup with vinum.
> I'd hate it if I'd have to migrate 300GB of data because I didn't reserve
> 16 sectors at the start of a disk :(

I don't know about official documentation, but Greg Lehey's instructions
on how to install FreeBSD on Vinum explicitly mentions offsetting the
"vinum" partition by 16 sectors to skip over the bootstrap.  (See
http://www.vinumvm.org/cfbsd/ for details.)  That is, however, for a
setup in which one boots from a Vinum volume...

Cheers,

Paul.
-- 
e-mail: paul_at_gromit.dlib.vt.edu

"Without music to decorate it, time is just a bunch of boring production
 deadlines or dates by which bills must be paid."
        --- Frank Vincent Zappa
Received on Sat Jun 26 2004 - 17:56:01 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:59 UTC