Joanne,
Am 30.06.18 um 11:24 schrieb jdow:
On 20180629 14:45, Martin Steigerwald wrote:
Beware: Essay ahead which proofs it to the point that there is no
overflow in RDB before 96 bits maximum value of sectors:
Time to go into more detail on RDBs. It isn't as simple as it started
to appear.
extract from hardblocks.h RDSK block definition
===8<---
ULONG rdb_BlockBytes; /* size of disk blocks */
...
ULONG rdb_Cylinders; /* number of drive cylinders */
ULONG rdb_Sectors; /* sectors per track */
ULONG rdb_Heads; /* number of drive heads */
...
ULONG rdb_LoCylinder; /* low cylinder of partitionable disk
area */
ULONG rdb_HiCylinder; /* high cylinder of partitionable data
area */
ULONG rdb_CylBlocks; /* number of blocks available per
cylinder */
===8<---
This has the hard limit embodied within it, unfortunately.
The first four values above give you hope for 2^128 bytes. The next
three may trash some of it when all three are considered.
Since a cylinder is sectors times heads we have 2^64 blocks capacity
embodied in rdb_LoCylinder and rdb_HiCylinder. But, our hopes are
deftly dashed by the last value rdb_CylBlocks which places a hard
limit on the product of rdb_Heads and rdb_Sectors of 2^32. But, that
still allows is a fairly large disk. 2^32-1 blocks per cylinder times
block size, rdb_BlockBytes, of 2^32, although the larger block sizes
are um er sort of putrid to use. Similar limitations exist within
dos.h in the InfoData and DosEnvec structure, among other likely places.
As far as Linux is concerned, rdb_CylBlocks is used nowhere, neither in
the RDB parser nor in the AFFS filesystem driver. Only the partition
list is parsed.
Should we use rdb_LoCylinder*rdbCylBlocks and
rdb_HiCylinder*rdbCylBlocks in the RDB parser to verify the detected
partitions are valid according to the RDB's own specified limits? Or can
we absolutely rely on the partitioning tool getting that right?
Any similar surprises in the partition list data structures? The header
I have in Linux is largely non-descriptive there:
struct PartitionBlock {
__be32 pb_ID;
__be32 pb_SummedLongs;
__s32 pb_ChkSum;
__u32 pb_HostID;
__be32 pb_Next;
__u32 pb_Flags;
__u32 pb_Reserved1[2];
__u32 pb_DevFlags;
__u8 pb_DriveName[32];
__u32 pb_Reserved2[15];
__be32 pb_Environment[17];
__u32 pb_EReserved[15];
};
As far as I can guess from the code, pb_Environment[3] (number of heads)
and pb_Environment[5] (number of sectors per cylinder) are abitrarily
chosen so the partition size can be expressed as a difference between
pb_Environment[9] and pb_Environment[10] (low and high cylinder
addresses), which places restrictions on both partition size and
alignment that depend on where on the disk a partition is placed?
Cheers,
Michael
Approaches "exist" to allowing large partitions. Some of them are
unattractive, probably all of them as a matter of fact.
1) For large disks move to GPT and be done with it.
2) "lie" and teach the filesystems to ignore rdb_CylBlocks and similar
values elsewhere. Then the sky is the limit.
3) Invent a "PA64" 64 bit RDB entry and the other internal structures
to make it work, InfoData64, DosEnvec64, and so on.
Solution 2 might be the least disruptive way to do it. BUT, a whole
host of utilities like "info" will have to be tweaked to handle
"rdb_CylBlocks" becoming meaningless.
So this is what happened with some simple includes mining while I am
playing hooky from doing some real work.
Good luck, gentlemen.
{^_^}
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
