I'll have to make time to look it over, considering I am more or less
the mommy of the RDBs. Now, 2TB may be a tad beyond the abilities of
the RDBs to express. Memory insists that the RDBs worked on either
BYTE or block counts. Your seeing a problem at 2TB suggests it really
stored bit counts. The numbers are supposed to be unsigned. And whether
the RDBs store values in blocks or BYTEs is immaterial when you get
down to it. (The RDBs do store the disk's actual and virtual block
sizes. The latter is what the filesystem uses.)
However, since C programs seek plus and minus in BYTEs you are stuck
with 31 bits worth of disk as your limit. That matches nicely with
your 31 bits. The RDBs should still be useful if you make sure to
plant them on block 1 or higher leaving block zero for other OSs and
you only use the first 2 TB for the Amiga OS files. (RDPrep and the
HDWrench library both exhibited a strong preference for starting the
RDB blocks on block 3 of the disk.)
{^_^} Joanne Dow, yeah, that antique broad.
On 2012/06/16 23:41, Martin Steigerwald wrote:
Hi Jens, hi Linux m68k developers,
I reported that as
https://bugzilla.kernel.org/show_bug.cgi?id=43511
I will attach there some more debug data like binary copy of RDB and such.
But maybe its easier to discuss here.
I am not sure whether its an issue with Linux or an issue with the RDB
format and disks with big sizes. But AFAIK RDB format is capable of
handling 2 TB disks.
With my 2 TB mixed Amiga/Linux backup disk, which I partioned under
AmigaOS 4.0/1 with Media Toolbox I get the following in Linux:
Jun 17 07:28:14 merkaba kernel: [30852.968978] sata_sil24 0000:05:00.0:
enabling device (0000 -> 0003)
Jun 17 07:28:14 merkaba kernel: [30852.969401] scsi9 : sata_sil24
Jun 17 07:28:14 merkaba kernel: [30852.969533] ata10: SATA max UDMA/100
host m128@0xf1c02000 port 0xf1c00000 irq 19
Jun 17 07:28:16 merkaba kernel: [30855.163712] ata10: SATA link up 3.0
Gbps (SStatus 123 SControl 0)
Jun 17 07:28:16 merkaba kernel: [30855.165014] ata10.00: ATA-8: Hitachi
HDS5C3020ALA632, ML6OA580, max UDMA/133
Jun 17 07:28:16 merkaba kernel: [30855.165017] ata10.00: 3907029168
sectors, multi 16: LBA48 NCQ (depth 31/32)
Jun 17 07:28:16 merkaba kernel: [30855.166378] ata10.00: configured for
UDMA/100
Jun 17 07:28:16 merkaba kernel: [30855.166477] scsi 9:0:0:0: Direct-Access
ATA Hitachi HDS5C302 ML6O PQ: 0 ANSI: 5
Jun 17 07:28:16 merkaba kernel: [30855.166653] sd 9:0:0:0: [sdb]
3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
Jun 17 07:28:16 merkaba kernel: [30855.166699] sd 9:0:0:0: [sdb] Write
Protect is off
Jun 17 07:28:16 merkaba kernel: [30855.166702] sd 9:0:0:0: [sdb] Mode
Sense: 00 3a 00 00
Jun 17 07:28:16 merkaba kernel: [30855.166726] sd 9:0:0:0: [sdb] Write
cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jun 17 07:28:16 merkaba kernel: [30855.200936] sdb: RDSK (512) sdb1
(LNX^@)(res 2 spb 1) sdb2 (JXF^D)(res 2 spb 1) sdb3 (DOS^C)(res 2 spb 4)
Jun 17 07:28:16 merkaba kernel: [30855.200943] sdb: p1 size
18446744072560312368 extends beyond EOD, enabling native capacity
Jun 17 07:28:16 merkaba kernel: [30855.201344] sdb: RDSK (512) sdb1
(LNX^@)(res 2 spb 1) sdb2 (JXF^D)(res 2 spb 1) sdb3 (DOS^C)(res 2 spb 4)
Jun 17 07:28:16 merkaba kernel: [30855.201347] sdb: p1 size
18446744072560312368 extends beyond EOD, truncated
Jun 17 07:28:16 merkaba kernel: [30855.201398] sdb: p2 start
18446744072560314432 is beyond EOD, truncated
Jun 17 07:28:16 merkaba kernel: [30855.201400] sdb: p3 start
18446744073189460080 is beyond EOD, truncated
Jun 17 07:28:16 merkaba kernel: [30855.201570] sd 9:0:0:0: [sdb] Attached
SCSI disk
The first partition seems to be way to big:
merkaba:~#1> amiga-fdisk -l /dev/sdc
Disk /dev/sdc: 3 heads, 16 sectors, 81396441 cylinders, RDB: 0
Logical Cylinders from 43 to 81396440, 24576 bytes/Cylinder
Device Boot Mount Begin End Size Pri BBlks System
/dev/sdc1 * 43 65536043 1572864024 0 0 Linux
native
/dev/sdc2 * 65536044 78643244 314572824 0 0
[unknown]
/dev/sdc3 * 78643245 81396440 66076704 0 0 Amiga
FFS Int.
(sdc2 is JXFS, a new filesystem in AmigaOS 4 that is not known to Linux
yet)
In cat /proc/partitions I get:
merkaba:~> cat /proc/partitions
major minor #blocks name
[…]
8 16 1953514584 sdb
8 17 1953513552 sdb1
merkaba:~>
Thus the Debian Linux Kernel 3.4.1 I am using here, truncates the first
oversized partition and has no space for the other, too, which therefore
are inaccessible under Linux.
I didn´t notice this initially, but it happened from the beginning, I have
an old amiga-fdisk listing that is exactly the same.
Amiga Mediatoolbox has a different oppinion on the partition layout:
LVM aka sdc1: 1500 GByte, 43 to 65536043 cyl, size 65536001 Zylinder
BAK aka sdc2: 300 GByte, 65536044 to 78643244 cyl, size 13107201 Zylinder
TAUSCH2 aka sdc3: 63,016 GByte, 78643245 to 81396440 cyl, didn´t note the
size here, but as far as I remember was okay as well
But it seems to be confused about the whole size of the disk as well:
Logical sizes:
Blocks per cylinder: 48
Cylinders: 81396441
Sectors: -397938128
Blocksize: 512
The sectors seem overflowed.
So it might be a problem with RDB and 2TB disks and nothing to do with
Linux. But still on AmigaOS 4.1 I can access the two Amiga partitions
after the Linux partition.
I have another 500GB disk for backup up my Sam440ep AmigaOS 4.1 "Amiga", I
plan to repartition the 2 TB disk as GPT anyway, but since MediaToolBox in
AmigaOS 4.1 has a different meaning about the partioning and this can cause
serious data loss, I think its good to look at it.
I had a BTRFS filesystem that had some checksum errors. Maybe thats somehow
related to this issue and AmigaOS and/or Linux overwrote something it
shouldn´t have touched.
I will report a bug with AmigaOS 4.1 developers as well to get more
details.
merkaba:~> cat /proc/version
Linux version 3.4-trunk-amd64 (Debian 3.4.1-1~experimental.1)
(debian-kernel@xxxxxxxxxxxxxxxx) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1
SMP
Wed Jun 6 10:34:53 CEST 2012
Ciao,
--
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
