> >> New page sizes are a new ODS anyway - old engines can't handle

them.

> >>
> >
> > Agreed, but a change to 32K would only be a minor ODS change.

> Uh, guys, a USHORT can handle 65,532 different values.

I thought it was 65,535! :-]

> We are anticipating pages sizes of 1k, 2k, 4k, 8k, 16k, 32k, and 64k.

Actually, I would suggest that page sizes of 128k, 256k, 512k, 1m and 2m
will also be very likely in the near future. These values would match
up with the disk page sizes that a number of RAID controllers *already*
support.

> Maybe some clever soul could find a way to represent x discrete values
> in 16 bits...

I think I'm clever so, I'll give it a shot.

{The fact that the engine already doesn't support page sizes < 1k, means
that we can low order values to store the mapping, and have the engine
detect the new 'mapped size' values.}

Therefore, I propose the following two mappings approaches:

Approach #1 (store values in number of k bytes)

1 (01h) = 1k
2 (02h) = 2k
4 (04h) = 4k
...
64 (40h) = 64k

This would have a "value less than 1024" page size limit of 512k
and an absolute page size limit of 4096k (4m)


Approach #2 (store values in number of 2^n k bytes)

0 = 1k
1 = 2k
2 = 4k
3 = 8k
4 = 16k
5 = 32k
6 = 64k
7 = 128k
...
10 = 1024k
...
15 = 32768k

This approach would have no practical page size limit, even
within values less than 1024.


Sean