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