Re: In-kernel units for block numbers, etc ...

[mlelstv%serpens.de@localhost (Michael van Elst)]

kre%munnari.OZ.AU@localhost (Robert Elz) writes:

>Unfortunately, once we add the "stacked" devices (cgd, and ccd for sure,
>perhaps lvm and raidframe, I haven't looked at those enough to know)
>the model breaks down, and we get incorrect conversions.

That isn't true.


>Currently at least cgd and (I believe) lvm just pretend that sectors
>are blocks,

Actually they just don't handle sector sizes. To make it correct,
they need to pass through that information from the lower layer.
For cgd that looks trivial, for LVM it probably requires some
larger code changes which is an issue if you want to keep it
in sync with Linux upstream.

Xen is another problem. There are good arguments to not inherit
the physical sector size but to fully simulate 512 byte sectors
(and there are arguments against it).


>ccd (especially if combining a 4k byte sector device with a 512 byte sector
>device) is simply a mess - perhaps almost a candidate for extermination.
>(Or maybe it can be resuscitated, who knows right now?)

CCD was invented when all disk devices had a single sector size, the
constant DEV_BSIZE. It has no idea how to handle mixed geometries.



>It has two disadvantages that I can see at the minute.   One is that it
>would require "large int" fields (at least 64 bits) everywhere,

It would also be conceptually identical to the current scenario where
the kernel _already uses byte offsets_ (it just doesn't store the low
9 bits which are always 0, thus preventing the use of sectors maller than
512 bytes).

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."