All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <Martin@lichtvoll.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: jdow <jdow@earthlink.net>,
	linux-kernel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
	linux-m68k@vger.kernel.org
Subject: Re: Partitions: Amiga RDB partition on 2 TB disk way too big, while OK in AmigaOS 4.1
Date: Mon, 18 Jun 2012 22:39:26 +0200	[thread overview]
Message-ID: <201206182239.26647.Martin@lichtvoll.de> (raw)
In-Reply-To: <CAMuHMdWY7=2nJDUjQFGPhdOAFGYeUsnvgPcaEvB2Gxf7P=E+Ug@mail.gmail.com>

Am Sonntag, 17. Juni 2012 schrieb Geert Uytterhoeven:
> On Sun, Jun 17, 2012 at 2:58 PM, Martin Steigerwald 
> <Martin@lichtvoll.de> wrote:
> > Am Sonntag, 17. Juni 2012 schrieb jdow:
> > | JXFS 64 bit file system
> > | 
> > | With AmigaOS 4.x a new file system has been introduced called JXFS.
> > | It is a totally new 64 bit file system that supports partitions up
> > | to 16 TB in size. It is a modern journalling file system, which
> > | means that it reduces data loss if data writes to the disk are
> > | interrupted. It is the fastest and most reliable file system ever
> > | created for AmigaOS.
> > 
> > http://www.amigaos.net/content/1/features
> > 
> > Well I asked AmigaOS 4 developers about this issue as well. Lets see
> > what they say about 2 TB limits.
> 
> 16 TB = 2 TB * 8. Perhaps they increased the block size from 512 to
> 4096?
> 
> block/partitions/amiga.c reads the block size from
> RigidDiskBlock.rdb_BlockBytes,
> but after conversion to 512-byte blocks, all further calculations are
> done on "int", so it will overflow for disks larger than 2 TiB.

Meanwhile I got a response from a AmigaOS 4 developer.

I documented the stuff as I understood it in the AmigaOS wiki:

| Disk size
|
| The RDB has a quite high limit on the maximum device size, but note that 
| currently each filesystem interprets the partition layout by itself.

| 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
|
| It's even much more if the sector size (rdb_BlockBytes and de_SizeBlock) 
| is larger than 512 bytes, but AmigaOS 4.1 doesn't support anything but 
| 512 bytes/sector HDs yet.
|
| Partition size
|
| For the partitions the maximum size is:
| 32 bit (de_HighCyl + 1 - de_LowCyl) (to get the partition size) * 32 bit 
| de_Surfaces * 32 bit de_SectorsPerTrack * 512 bytes/sector in struct 
| DosEnvec (=pb_Environment[]) in struct PartitionBlock.
|
| That's from the physical drive part, the actual disk size limit for the 
| partitions may be much smaller depending on the partitioning software, 
| if it's only using the logical sizes instead, which is likely the case, 
| it's only 8 ZiB with 512 bytes/sector: 32 bit rdb_HiCylinder * 32 bit 
| rdb_CylBlocks * 512 bytes/sector = 2^73 bytes. For using the logical 
| sizes using simple uint64 calculations (with some overflow checks) should 
| be enough, for more a math library with support for larger integers 
| needs to be used which probably no partitioning software does.
|
| But note: Nothing in struct RigiDiskBlock is used by the file systems for 
| mounting the partitions, they only get the information from the struct 
| PartitionBlock blocks, it's only a problem for the partitioning software 
| creating the partitions correctly - as soon as there are HDs larger than 
| 8 ZB while still using 512 bytes/sector if that ever happens.

http://wiki.amigaos.net/index.php/RDB

Please note that the documentation there might be updated or corrected in 
the future. But thats the current state.

> Note that in your profile-binary.img, the field is 0x200, i.e. 512
> bytes per block,
> so I'll have to get a deeper look into your RDB first...

I am a bit overwhelmed by Joanne´s analysis. I didn´t yet take time to 
completely read and try to understand it. I first wanted to get this 
information out.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

  parent reply	other threads:[~2012-06-18 20:39 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-17  6:41 Partitions: Amiga RDB partition on 2 TB disk way too big, while OK in AmigaOS 4.1 Martin Steigerwald
2012-06-17  8:24 ` Martin Steigerwald
2012-06-17 10:50 ` jdow
2012-06-17 12:58   ` Martin Steigerwald
2012-06-17 16:36     ` Geert Uytterhoeven
2012-06-17 21:06       ` Martin Steigerwald
2012-06-17 21:58         ` jdow
2012-06-18 21:14           ` Martin Steigerwald
2012-06-17 22:27         ` jdow
2012-06-17 21:06       ` jdow
2012-06-17 21:15         ` Geert Uytterhoeven
2012-06-17 22:09           ` jdow
2012-06-17 21:20         ` Martin Steigerwald
2012-06-17 22:17           ` jdow
2012-06-18  1:28           ` jdow
2012-06-19 19:46             ` Martin Steigerwald
2012-06-18 20:39       ` Martin Steigerwald [this message]
2012-06-18 20:58         ` jdow
  -- strict thread matches above, loose matches on Subject: below --
2012-06-17  8:33 Martin Steigerwald
2012-06-17 10:53 ` jdow
2012-06-17 12:51   ` Martin Steigerwald

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=201206182239.26647.Martin@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=axboe@kernel.dk \
    --cc=geert@linux-m68k.org \
    --cc=jdow@earthlink.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@vger.kernel.org \
    /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.