Bug 43521

Summary:	Amiga RDB partitions: truncates miscalculated partition size instead of refusing to use it
Product:	IO/Storage	Reporter:	Martin Steigerwald (Martin)
Component:	Block Layer	Assignee:	Jens Axboe (axboe)
Status:	NEW ---
Severity:	normal	CC:	glaubitz, szg00000
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:		Subsystem:
Regression:	No	Bisected commit-id:

Description Martin Steigerwald 2012-06-17 08:10:59 UTC

On investigating for bug #43511 I found:

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


Bug #43511 is about the apparently grossly miscalculated partition size.

This bug is about how to deal with it. Linux does the following:

1) it detects first partition sized beyond end of disk
2) it truncated first partition to *whole* harddisks size
3) it detects that second partition can´t fit anymore and truncates it to nothing
4) it detects that third partition can´t fit anymore and truncates it to nothing

merkaba:~> cat /proc/partitions 
major minor  #blocks  name
[…]
   8       16 1953514584 sdb
   8       17 1953513552 sdb1


This is a pretty serious data loss issue.

Linux overwrites the Amiga partitions. AmigaOS 4.1 sees the Amiga partitions and overwrites the Linux LVM. At leasdt when there are logical volumes on top of them.


A sane behaviour IMHO would be:

1) it detects first partitions sized beyond end of disk

2) it refuses to detect and use *any* partition on the disk.


Granted this might make a disk unaccessible.

But then it won´t destroy the data on it.

So I´d prefer that I have to fix things manually instead of having checksum errors in may backup.

What do you think? I think its good to change the current behavior.

Also I think its good whether that issue also exists in other partition detect code in Linux.

Thanks,
Martin

Comment 1 Martin Steigerwald 2012-06-17 08:46:31 UTC

Hmmm, I missed the pvdisplay and vgdisplay output:


merkaba:~> pvdisplay /dev/sdb1
  --- Physical volume ---
  PV Name               /dev/sdb1
  VG Name               steigerwald
  PV Size               1,82 TiB / not usable 4,08 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              476931
  Free PE               105731
  Allocated PE          371200
  PV UUID               ZXMECC-JAir-lX8Q-rLhS-W1cS-quwz-b3FXWp

merkaba:~> vgdisplay steigerwald
  --- Volume group ---
  VG Name               steigerwald
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  7
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                5
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               1,82 TiB
  PE Size               4,00 MiB
  Total PE              476931
  Alloc PE / Size       371200 / 1,42 TiB
  Free  PE / Size       105731 / 413,01 GiB
  VG UUID               uhjjE1-0yrD-Ch1A-d9qL-P5jY-UDXE-io4bpi


You can see both physical volume and volume group span the entire disk. While
they shouldn´t cause there are two other partitions on the 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.