From: jdow <jdow@earthlink.net>
To: Michael Schmitz <schmitzmic@gmail.com>,
Martin Steigerwald <martin@lichtvoll.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Jens Axboe <axboe@kernel.dk>,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
linux-block@vger.kernel.org
Subject: Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB
Date: Fri, 29 Jun 2018 17:57:51 -0700 [thread overview]
Message-ID: <8d6f91bc-17f9-bed2-21f1-81bf18d49fc3@earthlink.net> (raw)
In-Reply-To: <b7558aec-1a69-6004-adde-7ac77e304fe4@gmail.com>
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. 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.
{^_^}
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.
>> {^_^}
>
next prev parent reply other threads:[~2018-06-30 0:57 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-27 1:24 Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB schmitzmic
2018-06-27 8:13 ` Martin Steigerwald
2018-06-28 3:23 ` jdow
2018-06-27 8:24 ` Martin Steigerwald
2018-06-27 20:13 ` Michael Schmitz
2018-06-27 21:20 ` Martin Steigerwald
2018-06-28 3:48 ` jdow
2018-06-28 4:58 ` Michael Schmitz
2018-06-28 6:45 ` Geert Uytterhoeven
2018-06-28 7:13 ` Martin Steigerwald
2018-06-28 9:25 ` Geert Uytterhoeven
2018-06-29 8:42 ` Michael Schmitz
2018-06-29 8:51 ` Geert Uytterhoeven
2018-06-29 9:07 ` Michael Schmitz
2018-06-29 9:12 ` Geert Uytterhoeven
2018-06-29 9:25 ` Michael Schmitz
2018-06-29 21:24 ` Martin Steigerwald
2018-06-29 23:24 ` Michael Schmitz
2018-06-30 0:49 ` jdow
2018-06-29 21:17 ` Martin Steigerwald
2018-06-29 9:32 ` jdow
2018-06-29 21:45 ` Martin Steigerwald
2018-06-29 23:24 ` jdow
2018-06-30 0:44 ` Michael Schmitz
2018-06-30 0:57 ` jdow [this message]
2018-06-30 1:31 ` Michael Schmitz
2018-06-30 3:56 ` jdow
2018-06-30 5:26 ` Michael Schmitz
2018-06-30 6:47 ` jdow
2018-06-30 9:07 ` Martin Steigerwald
2018-06-30 9:39 ` jdow
2018-06-30 8:48 ` Martin Steigerwald
2018-06-30 9:28 ` jdow
2018-06-30 7:49 ` Martin Steigerwald
2018-06-30 9:36 ` jdow
2018-07-01 2:43 ` Michael Schmitz
2018-07-01 4:36 ` jdow
2018-07-01 12:26 ` Martin Steigerwald
2018-06-29 12:44 ` Andreas Schwab
2018-06-30 21:21 ` Geert Uytterhoeven
2018-06-29 21:10 ` Martin Steigerwald
2018-06-28 9:20 ` jdow
2018-06-28 9:29 ` Geert Uytterhoeven
2018-06-29 8:58 ` Michael Schmitz
2018-06-29 9:10 ` Geert Uytterhoeven
2018-06-29 9:19 ` Michael Schmitz
2018-06-28 7:28 ` Martin Steigerwald
2018-06-28 7:39 ` Geert Uytterhoeven
2018-06-28 9:34 ` jdow
2018-06-28 3:49 ` jdow
2018-06-27 13:30 ` Geert Uytterhoeven
2018-06-27 20:43 ` Michael Schmitz
2018-06-28 3:45 ` jdow
2018-06-29 9:12 ` Michael Schmitz
2018-06-30 21:10 ` Geert Uytterhoeven
2018-06-30 21:26 ` Michael Schmitz
2018-07-02 5:29 ` [PATCH] block: fix Amiga partition support for disks >= 1 TB Michael Schmitz
2018-07-02 6:38 ` Kars de Jong
2018-07-02 22:34 ` Michael Schmitz
2018-07-02 8:29 ` Geert Uytterhoeven
2018-07-02 23:58 ` Michael Schmitz
2018-07-03 7:22 ` Geert Uytterhoeven
2018-07-03 8:15 ` Michael Schmitz
2018-07-03 10:02 ` jdow
2018-07-02 19:36 ` Martin Steigerwald
2018-07-02 19:39 ` Martin Steigerwald
2018-07-03 7:19 ` [PATCH v2] " Michael Schmitz
2018-07-03 19:39 ` [PATCH v3] " Michael Schmitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8d6f91bc-17f9-bed2-21f1-81bf18d49fc3@earthlink.net \
--to=jdow@earthlink.net \
--cc=axboe@kernel.dk \
--cc=geert@linux-m68k.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=martin@lichtvoll.de \
--cc=schmitzmic@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.