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