tagging disk requests (geom-related)

Poul-Henning Kamp phk at phk.freebsd.dk
Fri Jan 9 06:36:30 PST 2009


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.

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.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


More information about the freebsd-arch mailing list