Joanne,
Am 30.06.18 um 15:56 schrieb jdow:
>
> >>> 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
> How long did it tale s to get to 10 TB disks from 2 TB disks. And a
> new SD Card spec allows for 128 TB disks. Block sizes get sort of
> ridiculous as you get past about 8k bytes or about 32 TB or about two
> years from now.
I get that - I just don't get why 32 bits for cylinders plus 32 bits for
blocks per cylinder equals 2 TB (4G of 512 byte blocks). But I don't
know what other limits exist that may restrict the total number of
blocks to 32 bits.
>
> Do you want to create disks that will fail on AmigaDOS? AmigaDOS, as
> far as I know, makes heavy use of Cylinder Blocks values. It
> calculating Cylinder Blocks overflows when creating the disk's RDBs
> the user MUST be informed it is
I'm not at all planning to create disks for AmigaDOS. I just need to
know what combinations of cylinders, heads and sectors are possible to
encounter on disks that have been created with native tools. Well,
assuming sufficient amounts of braindamage in the corresponding Linux
tools, knowing the absolute outer limits of what these tools could do
would be nice as well, but someone using amiga-fdisk to create a RDSK
block for a 10 TB disk fully deserves any punishment that invites.
(Actually, I lied there. I do plan to create a RDSK block for a 2 TB
disk image where cylinder, head and sector counts all approach the 32
bit limit, just to see that my overflow checks work as intended. But
that's strictly for Linux testing).
> unsafe to put on a real Amiga. (I'd also suggest teaching Linux to
> understand RDSL, which would be RDSK++ sort of. Then use that if
> Cylinder Blocks overflows.) The value you will not be able to fill in
> the DosEnvec structure is:
> ULONG de_HighCyl; /* max cylinder. drive specific */
OK, so Cylinder Blocks overflowing is a red flag, and requires to abort
parsing the partition table right away? And HighCyl really means the
max. number of logical blocks, not cylinders (which would have
nr_heads*nr_sects many blocks)? That's probably the cause for my confusion.
>
> So accessing larger disks once you hit 2 TB means you must increase
> the logical block size. And eventually that will waste HUGE amounts of
> files when small files are being stored.
Just like small inodes wastes huge amounts of space for metadata. It's a
tradeoff, and AFFS on a RDSK format disk probably isn't the right choice
for huge disks. Never mind that - if someone _does_ go that way, we need
to make sure we can parse the RDSK information correctly. And if such a
disk causes the 64 bit sector_t in Linux to overflow, I'd like the
parser to spot that, too.
Thanks for your immense patience in explaining all these subtleties to me.
Cheers,
Michael
>
> Any solution will require action on the part of the people developing
> AmigaDOS follow-ons. You might want to get them motivated, somehow,
> and proceed from there with a request to be informed of any RDB
> changes. I'd suggest to them that removing sensitivity to Cylinder
> Blocks sorts of values from the entire system probably would be
> painful but the simplest solution.
>
> {^_^}
> --
> 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
