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��.n��������+%������w��{.n�����{��n����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
