From owner-freebsd-arch@FreeBSD.ORG Fri Jan 9 14:31:39 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A546106564A for ; Fri, 9 Jan 2009 14:31:39 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id E29178FC16 for ; Fri, 9 Jan 2009 14:31:38 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 1840773098; Fri, 9 Jan 2009 15:36:41 +0100 (CET) Date: Fri, 9 Jan 2009 15:36:41 +0100 From: Luigi Rizzo To: Poul-Henning Kamp Message-ID: <20090109143641.GA19478@onelab2.iet.unipi.it> References: <20090109130911.GA17017@onelab2.iet.unipi.it> <22308.1231510855@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22308.1231510855@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, fabio@gandalf.sssup.it Subject: Re: tagging disk requests (geom-related) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 14:31:39 -0000 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