Date: Sat, 20 Dec 2014 21:21:01 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Adrian Chadd <adrian@freebsd.org> Cc: John-Mark Gurney <jmg@funkthat.com>, "Pokala, Ravi" <rpokala@panasas.com>, "freebsd-geom@freebsd.org" <freebsd-geom@freebsd.org> Subject: Re: Converting LBAs to byte offsets through the GEOM stack Message-ID: <13564.1419110461@critter.freebsd.dk> In-Reply-To: <CAJ-Vmomm2yst=NN6hYopY7DR_Nw=HDa2v-Y9xtqji8xZn5b92A@mail.gmail.com> References: <D0B89F30.127DAE%rpokala@panasas.com> <20141219015210.GY25139@funkthat.com> <D0B8C76C.127E55%rpokala@panasas.com> <CAJ-VmokV3-ZRQmVZWcHUSxccwaRxySDExoSiF8%2BsgHtkHN5_yg@mail.gmail.com> <D0BB136C.1280A4%rpokala@panasas.com> <CAJ-Vmomm2yst=NN6hYopY7DR_Nw=HDa2v-Y9xtqji8xZn5b92A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--------
In message <CAJ-Vmomm2yst=3DNN6hYopY7DR_Nw=3DHDa2v-Y9xtqji8xZn5b92A@mail.g=
mail.com>
, 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=
.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13564.1419110461>