On Sat, Jun 26, 2004 at 05:45:51PM +0200, Lukas Ertl wrote: +> On Sat, 26 Jun 2004, Pawel Jakub Dawidek wrote: +> +> >On Sat, Jun 26, 2004 at 02:07:03PM +0200, Lukas Ertl wrote: +> >+> 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. The second problem is the on-disk format of a +> >+> bsdlabel. As far as I understand it, this meta-data is stored inside +> >+> the first partition, so when you open the drive for writing (i.e. +> >+> mount, fsck) you trigger a spoil event which cause all kinds of +> >confusion +> >+> for geom_vinum. +> > +> >I don't know exactly what problems you got, but maybe it can help you: +> >To avoid spoiling and metadata changes under me, I'm opening every +> >provider, which I want to use in geom_mirror (r1w1e1), even if provider +> >which I create isn't yet opened. +> +> This was a good tip, but unfortunately it still doesn't work out. I +> always run into the 'spoiled but dcr = %d' KASSERT. Unfortunately, kernel +> debugging is currently rather a 'guessing' since kgdb doesn't work. The +> next problem is that you might specify /dev/da1s1a as vinum drive but get +> /dev/da1s1c or even /dev/da1s1. 'Classic vinum' looked at the type field +> in the disklabel, but we don't do this anymore. This is a race in GEOM. I'm using a patch for this when I running geom_mirror. I sent it to phk more than week ago (AFAIR) and I still didn't get an answer. Try if it works you: http://people.freebsd.org/~pjd/patches/geom_subr.c.16.patch -- Pawel Jakub Dawidek http://www.FreeBSD.org pjd_at_FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am!
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:59 UTC