Beware: Essay ahead which proofs it to the point that there is no overflow in RDB before 96 bits maximum value of sectors: jdow - 29.06.18, 11:32: > On 20180629 01:42, Michael Schmitz wrote: > > Hi Geert, > > > > Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven: > >>>> Do we really need the warning? > >>>> Once the parsing is fixed doing 64-bit math, it does not matter > >>>> for > >>>> Linux anymore. > >>> > >>> Well, irony of this is: In my case the RDB has been created on a > >>> machine with a native OS. So Linux warns me about something I > >>> already did so on the native OS without any warning. In this case > >>> AmigaOS 4.0.>> > >> Exactly. > >> > >> So moving a disk partitioned under AmigaOS 4.0 to a system running > >> an > >> older version of AmigaOS can fail miserably. Not a Linux issue. > >> Linux also doesn't warn about disks with GPT failing to work on old > >> MSDOS.> > > Would MSDOS recognize the GPT partition as 'probably FAT', and > > attempt to use it? > > I believe it would fail to mount it and suggest formatting it. The key > is to fail the mount and not risk damage to the data on it. > > >> Let me clarify: what exactly would the kernel option allow? When to > >> use it?> > > Whether to use it if safe (on Linux). But whatever Linux does (after > > this patch), access will go to the right area of the disk (as > > specified by the RDB) so Linux won't any longer stomp on anything > > that would have mattered to 32 bit disk drivers. So it really > > should be safe. > Martin pointed out something privately about RDBs I'd forgotten over > the archeological eras gone past. The RDB values are all 32 bit > unsigned longs. That means as long as they are properly promoted AND > the file system does not barf from a gross overfeeding disks up to > about 2^128 bytes can be supported. But you need a new uint128_t > datatype. So for Amigas or Linux the real limitation is the data type > and significance that flows between the RDB parser and the file > system. That is the value that has to be considered. Then if the > filesystem somewhere inside coughs up a hairball over some internal > overflow or other and cannot accept say a full uint64_t maximum value > of bytes with grace and polish it should error out when it sees an > incoming disk positions off its internally acceptable range. I think I pointed it out publically as well. I did in the other thread "Re: Amiga RDB partition support for disks >= 2 TB". Just for the record in an reply to your patch, Michael, I copy it over: ------------------------------------------------------------------------- But yeah, as mentioned I researched the topic before. And I think there has not even been an overflow within the RDB: > The raw, theoretical limit on the maximum device capacity is about > 2^105 bytes: > > 32 bit rdb_Cylinders * 32 bit rdb_Heads * 32 bit rdb_Sectors * 512 > bytes/sector for the HD size in struct RigidDiskBlock http://wiki.amigaos.net/wiki/RDB_(Amiga_Rigid_Disk_Block) Confirmed by: The .ADF (Amiga Disk File) format FAQ: http://lclevy.free.fr/adflib/adf_info.html#p6 But what do I write, you know the RDB format So just do the calculation in 96 Bit and you all are set Now that is a reason for 128 Bit CPUs :). ------------------------------------------------------------------------- > Here are the relevant pieces of the ADF format FAQ: > 6.1 What is the Rigid Disk Block ? > > * Rigid Disk block (256 bytes) must exist within the first 16 blocks > […] > > Physical drive caracteristics > > 64/40 ulong 1 cylinders number of drive cylinder > 68/44 ulong 1 sectors sectors per track > 72/48 ulong 1 heads number of drive heads > […] ULONG is 32-bit unsigned. See: http://wiki.amigaos.net/wiki/Fundamental_Types So we basically have 96 bits here + at least 9 bits (512 bytes sector size) if you calculate by bytes. And as noted by Joanne: In case you would use large sector sizes… you could address really even more *insane* amounts of capacity. See why I still think RDB´s is quite brilliant? Maybe using ULONG was just by accident, but well it made RDB´s future proof for accessing larger disks than anything that is in the market today and I bet for a long time to come :) And for partitions this works as well: > 6.3 How are partitions stored? > > 164/a4 ulong 1 LowCyl first cylinder of a partition > (inclusive) > 168/a8 ulong 1 HighCyl last cylinder of a partition > (inclusive) So to summarize: I think RDB´s can compete with GPT regarding maximum capacity nicely enough. Despite Joanne invented RDB at least a decade before someone invented GPT. AmigaOS had and has a ton of flaws but it has been made by genius´es and it is a lot of brilliant ideas in it. Okay, I think after this essay it should really be clear that the RDB itself can handle insane amounts of capacity in any case. > This means that any errors and failures to mount should lie with the > RDB Parser, the filesystem, the device driver, and any intervening > code between the three. The RDBs can express a value far greater than > the number of atoms estimated to exist in the observable universe. So > RDBs won't ever need a change for disk size considerations. The > parser and filesystems probably and possibly, respectively, will. Exactly that. Filesystems have other limits. And they need to bail out before mounting anything beyond their limits. So the RDB parser is just fine with at least 64 bit calculations. Of course it should bail out big time if it ever comes across a RDB where 32 bit rdb_Cylinders * 32 bit rdb_Heads * 32 bit rdb_Sectors does not fit within 64 Bit. Unless it uses 96 or even 128 bit calculations :). Even tough I think it is unlikely that there ever would be such an RDB, I would rather play it very safe with anything regarding partitioning and addressing capacity on disks. Never ever overflow without bailing out. Or to have it with Joanne´s words: > Error out and don't mount disks or partitions that are outside the > size range your element of the datapath from disk to user's program > can handle at the first place this can be detected. It's the polite > thing to do to a user's data rather than the Maxine Waters thing to > do. Fully agreed. Amen, -- Martin
