From owner-freebsd-arch@FreeBSD.ORG Fri Jan 9 14:36:30 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 439911065670 for ; Fri, 9 Jan 2009 14:36:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 07A918FC13 for ; Fri, 9 Jan 2009 14:36:29 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 07E873F12F; Fri, 9 Jan 2009 14:20:55 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n09EKtaY022309; Fri, 9 Jan 2009 14:20:55 GMT (envelope-from phk@critter.freebsd.dk) To: Luigi Rizzo From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Jan 2009 14:09:11 +0100." <20090109130911.GA17017@onelab2.iet.unipi.it> Date: Fri, 09 Jan 2009 14:20:55 +0000 Message-ID: <22308.1231510855@critter.freebsd.dk> Sender: phk@critter.freebsd.dk 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:36:30 -0000 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. 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@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.