Date:        Mon, 20 Oct 2003 19:12:54 +0100
    From:        David Laight <david@l8s.co.uk>
    Message-ID:  <20031020191254.B9975@snowdrop.l8s.co.uk>

  | Oh, how do you intend to squeeze 64bit offset and size into the 16byte
  | disklabel entry?

This is truly ugly, but we could borrow from tcp window scaling, and
add a scale factor.

eg: at the minute there's a 32 bit field that holds the sector size
of the drive.   I don't know about you, but I'd guess that 24 bits for
that would be big enough for all time ... take the top 8 bits (which
will be zero in all current labels, as the sector size currently is
going to be no more than about 8K for sure, and probably 512 in every
case that matters) and break that into 2 4 bit fields (m & n).

If m == 0, no scaling is being done.   Everything as now.

If m != 0, then "all relevant numbers" in the label get multiplied
by m*2^n.    That gives us up to 7*2^15 as a max scale factor
(and down to just 2 or 3 - actually also 1, but that's useless).

If I did the sums correctly, that would allow almost a 500 million
GB drive (binary GB) - or just over 500 million GB disk manufacturer
GB's (decimal GBs).   No idea what that translates into in TBs or PBs,
but it is big.   It will probably last a year or two.

The "all relevant numbers" includes sectors on the drive, partition
offsets and sizes, and anything else that scales with the size of the
drive.

The effect would be not being able to put partition boundaries just
anywhere, but only at a multiple of the scale factor - and that the total
space on the drive may get truncated by one scale factor size - but even
at the biggest, that's only of the order of 100MB, which on a 500 million
GB drive is nothing...

Of course, this is just a wild idea  .... it would also be for on drive
use only - numbers would get unpacked into bigger fields when the label
was read, so code currently using the label wouldn't need many changes,
only the code that creates it, to know the limitations, and pick a scale
factor.

kre