kern/133604: [gvinum] [panic] writing to gjournal on a gvinum volume

Ulf Lilleengen lulf at FreeBSD.org
Tue Apr 21 10:30:03 UTC 2009


On tir, apr 21, 2009 at 12:28:02pm +0200, Pawel Jakub Dawidek wrote:
> On Tue, Apr 21, 2009 at 01:16:00PM +0200, Ulf Lilleengen wrote:
> > On tir, apr 21, 2009 at 11:30:11am +0200, Pawel Jakub Dawidek wrote:
> > > The bio_cflags field is for consumer use only (in this case gjournal. As
> > > provide you should use bio_pflags.
> > > 
> > Yes, but shouldn't cflags be used for the BIOs that gvinum issue downwards
> > when it is a consumer? Like this:
> > 
> > gjournal (consumer)
> >    |
> >  gvinum (provider)
> >  gvinum (consumer)
> >    |
> >  disk  (provider)
> > 
> > I think the problem is that it has to check where the BIO comes from when
> > picking a BIO from the input queue. In this case, it misinterpreted the
> > gjournal BIO as an internal DONE bio, so if the originator of the BIO is
> > known, it can determine if cflags is actually its own. Is this making sense?
> 
> One never passes received bio down, but instead bio is cloned, modified
Yes, that's what I meant.

> and passed down, so in your case:
> 
> gjournal (consumer)
>   |
>  bio1
>   |
> gvinum (provider)
> gvinum (consumer)
>   |
>  bio2
>   |
> disk (provider)
> 
> You can use bio1->bio_pflags and bio2->bio_cflags.
> 
> If you have the same queue for incoming and completed bios you might be
> able to find out which is which by checking bio_to/bio_from fields for
> example.
> 
Mhm, I have a patch for that, just wanted to make sure it's an okay way to do
it, thanks :)

-- 
Ulf Lilleengen


More information about the freebsd-geom mailing list