Converting LBAs to byte offsets through the GEOM stack

[Poul-Henning Kamp]

--------
In message <CAJ-Vmomm2yst=NN6hYopY7DR_Nw=HDa2v-Y9xtqji8xZn5b92A at mail.gmail.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 at 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.