On Sat, 14 May 2011 10:21:59 +0200 Louis-David Mitterrand <vindex+lists-linux-raid@xxxxxxxxxxx> wrote: > On Sat, May 14, 2011 at 07:33:47AM +1000, NeilBrown wrote: > > On Fri, 13 May 2011 22:29:01 +0200 Louis-David Mitterrand > > <vindex+lists-linux-raid@xxxxxxxxxxx> wrote: > > > Each disk is configured thus: > > > > > > Disk /dev/sda: 1000.2 GB, 1000204886016 bytes > > > 255 heads, 63 sectors/track, 121601 cylinders > > > Units = cylinders of 16065 * 512 = 8225280 bytes > > > Sector size (logical/physical): 512 bytes / 512 bytes > > > I/O size (minimum/optimal): 512 bytes / 512 bytes > > > Disk identifier: 0x05022e04 > > > > > > Device Boot Start End Blocks Id System > > > /dev/sda1 1 32 257008+ fd Linux raid autodetect > > > /dev/sda2 33 17500 140311710 fd Linux raid autodetect > > > /dev/sda3 17501 121601 836191282+ fd Linux raid autodetect > > > > > > > Is this the config reported with the old controller or with the new > > controller? > > Sorry for the confusion, the above was with the old (LSI) controller. > This is the disk geometry with the new (Adaptec) controller: > > Disk /dev/sda: 1000.1 GB, 1000104157184 bytes > 255 heads, 63 sectors/track, 121589 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x6397e8f6 > > Device Boot Start End Blocks Id System > /dev/sda1 1 32 257008+ fd Linux raid autodetect > /dev/sda2 33 17500 140311710 fd Linux raid autodetect > /dev/sda3 17501 121601 836191282+ fd Linux raid autodetect > > Ah! 121589 vs 121601 cylinders... > > > Because my guess is that the new controller makes the devices look a little > > bit smaller. That would cause the kernel to reject them, but quite possibly > > allow mdadm to think they look OK. > > > > It would also explain why the first 2 partitions work fine and only the last > > one is a problem. > > > > If this were the case I would expect a message like: > > "%s: p%d size %llu extends beyond EOD > > Spot on: > > May 14 10:15:46 zenon kernel: sda: p3 size 1672382565 extends beyond EOD, trunca > ted > > Is there any solution other than backuping my /dev/md2 somewhere with > the old controller and re-creating a (slightly) smaller one with the new > controller? If the filesystem is ext3, then with the old controller you could resize2fs the filesystem to be several megabytes smaller - aim to over-shrink rather than under-shrink. Say 2 Meg per devices, so 12Mmeg ... so maybe 20Meg for safety... or even double that again. Then use mdadm to make the array smaller (mdadm --grow --size=whatever). Then 'fsck -f' the filesystem to make sure it is still OK. If you messed up you can still make the size bigger again with mdadm. The 'size' is the per-device size, so 1/6 of the array size, but a multiple of the chunk size. Then switch back to the new controller and assemble with --update=devicesize so: mdadm -A /dev/md2 --update=devicesize /dev/sd[abcdefg]3 and it should all work. If you don't have ext3, then you probably need to backup and restore - I don't think other filesystems support shrinking, but I could be wrong. NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
