Date: Fri, 9 Jan 2009 15:36:41 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@freebsd.org, fabio@gandalf.sssup.it Subject: Re: tagging disk requests (geom-related) Message-ID: <20090109143641.GA19478@onelab2.iet.unipi.it> In-Reply-To: <22308.1231510855@critter.freebsd.dk> References: <20090109130911.GA17017@onelab2.iet.unipi.it> <22308.1231510855@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 09, 2009 at 02:20:55PM +0000, Poul-Henning Kamp wrote: > In message <20090109130911.GA17017@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. thanks luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090109143641.GA19478>