From owner-freebsd-geom@FreeBSD.ORG Sat Dec 20 21:21:12 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 690D7BB4; Sat, 20 Dec 2014 21:21:12 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 25E701E84; Sat, 20 Dec 2014 21:21:11 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 73D983BD1A; Sat, 20 Dec 2014 21:21:04 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id sBKLL1N9013565; Sat, 20 Dec 2014 21:21:01 GMT (envelope-from phk@phk.freebsd.dk) To: Adrian Chadd Subject: Re: Converting LBAs to byte offsets through the GEOM stack In-reply-to: From: "Poul-Henning Kamp" References: <20141219015210.GY25139@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13563.1419110461.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 20 Dec 2014 21:21:01 +0000 Message-ID: <13564.1419110461@critter.freebsd.dk> Cc: John-Mark Gurney , "Pokala, Ravi" , "freebsd-geom@freebsd.org" X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 21:21:12 -0000 -------- In message , Adrian Chadd writes: >The only thing that knows about the current state of the mapping is >that black box. In the original sketches for GEOM, almost 20 years ago (!) there were a maintenance facility to ask; "where does this byterange on this provider end up?" That turned out to become a major headache to implement. First of, there is not a 1:1 correspondence in sight anywhere. A single provider can have multiple open consumers and you have to ask them all how they feel about it. Next, something like GBDE or RAID5 will turn your single sector into a range of sectors, and that is the simple case. Imagine a MBR label, with "extended partitions" which are effectively a linked list, and your query interval is one of these pseudo-linked-list- MBR-sectors, suddenly the answer becomes "a large fraction of the disk". Once you start to think about this, it can get really icky: There is no guarantee that the mapping is one-interval onto another-interval, it could return N intervals. Now, please design a sensible datastructure to capture that... And second: All this happens the wrong way around: It starts at the bottom and works its way up the GEOM stack, which means that lock-inversions is the dish-of-the-day every single place. In the end I simply dropped it: The complexity would in no way justify putting the necessary code in the kernel. If this were important, the geom(8) tool could probably do it, based on the exported XML state of the geom-mesh and support modules mirroring actual logic for all relevant geoms, that way it would at least live in userland. -- = 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= .