Joanne,
Am 30.06.18 um 12:57 schrieb jdow:
> On 20180629 17:44, Michael Schmitz wrote:
>
> > 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];
> > };
> pb_Environment = a struct DosEnvec and it is 20 ULONGs in size. I
> believe you are looking at some old include files.
Without looking at ancient git history, I'd say between 1993 and 1996.
> These got added to the end of the DosEnvec structure:
> ULONG de_Baud; /* Baud rate for serial handler */
> ULONG de_Control; /* Control word for handler/filesystem */
> ULONG de_BootBlocks; /* Number of blocks containing boot code */
>
> > 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?
> If you do not teach the OS to ignore Cylinder Blocks type entries and
> use some math on heads and blocks per track the disk size is
> relatively stuck modulo using large blocks.
As long as AmigaOS and Linux agree on how to express start and end
offset for the partitions, that's fine.
But I read your other mail to mean that we're stuck to 2 TB disks for
now. I don't follow that - we can have partitions of 2 TB each by maxing
out rdb_CylBlocks as long as we use 512 bytes per block (since the
product of cylinders and blocks per cylinder is limited to 32 bits) and
using one cylinder per partition (32 bits available there as well)?
But the rdb_CylBlocks limit also means we're safe with 64 bit sector_t
in Linux. Best add a check in the parser to warn us if the product of
head count and sectors per cylinder overflows 32 bit though.
Cheers,
Michael
>
> {^_^}
>
> On 20180629 17:44, Michael Schmitz wrote:
>> 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.
>>> {^_^}
>>
