tagging disk requests (geom-related)

Luigi Rizzo rizzo at iet.unipi.it
Fri Jan 9 06:31:39 PST 2009

On Fri, Jan 09, 2009 at 02:20:55PM +0000, Poul-Henning Kamp wrote:
> In message <20090109130911.GA17017 at onelab2.iet.unipi.it>, Luigi Rizzo writes:
> >    (Background for non geom-aware people: each request is identified
> >    by a 'struct bio' (BIO);
> Strictly speaking, the bio *is* the request :-)
> >For #1, to avoid adding a field to 'struct bio', we store the tag
> >in the bio_caller1 field (if available) of the root element of the
> >BIO tree, bio_caller1 is normally unused (except by ZFS), and we
> >say it is available if it contains NULL.
> This is wrong, bio_caller1 is for the caller to store private
> information, you should not hi-jack it.
> >Re #2, we can put the code that does the marking either in the place
> >where the root BIO is created (but there may be many such places,
> >and especially they can be in external modules that we are not even
> >aware of), or hook into a central place, g_io_request(), and walk
> >up the BIO tree until we find the root:
> This will not work, some GEOM classes initiate bios, (RAID5 parity
> stripes for instance.
> It is also really stupid to walk the chain repeatedly like this.
> >The alternative approach is adding one field to the struct bio -- in this
> >case the marking could just be done on the current BIO in g_io_request,
> >and propagated down in g_clone_bio() (or just in the lookup, walk
> >up the tree to the topmost marked bio).
> That's the way to go.

I agree. Probably there is no other reliable way.
The unfortunate drawback of this approach is that it changes
the size of the bio (so you need a full rebuild of kernel and modules),
that's why I was hoping for a possibly unused field in the topmost bio
to store the tag.

> Also, and please make sure you understand the depth of this suggestion
> before you dismiss it:
> Instead of recording the identity of the originator, you should
> record a struct containing capabilities of the originator, one
> of which could be the identity.

yes, as i said in the original post the details are irrelevant now,
i just needed a place to hook the additional info to the bio.
Once i have that, i can do all details i need.


More information about the freebsd-arch mailing list