Hi David, On 07/27/2016 03:13 AM, David C. Rankin wrote: > Chris, Phil, All, > > Thank you. For anyone else that is faced with the problem where you are using > whole disks in your raid1 array over the top of unused sub-partitions, here is > the 5 minute fix. Glad you got it sorted out. > How I solved the problem: > > (1) do NOT attempt to alter the disk in a partitioning package like fdisk, > sfdisk, gdisk, parted, etc.. A write after you delete the unused partitions with > adversely affect the md data and will require a long and painful resync > depending on the size of your drive. Correct. > (2) simply --fail and --remove one drive from the array. My array was > /dev/md4, and failing and removing /dev/sdd from the array was as simple as: > > # mdadm /dev/md4 --fail /dev/sdd > # mdadm /dev/md4 --remove /dev/sdd Unnecessary, and you have no redundancy for the duration. Using dd to wipe the first 4k of a v1.2 array member is entirely safe to do while running. > (3) To remove the inadvertent partition on the drive while keeping the raid > data in tact, you must remove the PMBR and primary Partition tables from the > drive. You can use `wipefs` or simply use `dd` to overwite the first 4096 bytes > on the drive with zeros and then the last 1024 bytes before the end of the disk > to remove the backup GPT header. (I overwote the last 4096 bytes on the disk, > just to make sure -- I had nothing in the last 100M of the disk, so that seemed > fine) You can look at the disk geometry reported by gdisk to find the end of the > disk (the number of logical sectors -- make sure the disk has 512-byte sectors, > or dd option adjustments will be needed) (then just subtract 8 from that number > (or 2 if you wish to limit the write to 1024 bytes) and use that as the 'seek' > offset with 'dd', so > > # dd of=/dev/sdd if=/dev/zero bs=4096 count=1 > # dd of=/dev/sdd if=/dev/zero bs=512 count=8 seek=5860533160 I always place of=/dev/.... last on a dd command line just in case. Using dd to write near the end of a member device is entirely safe while running if the location is after the "Used Data Area"+"Data Offset" of the device, as reported by mdadm --examine. If you are zeroing a backup GPT that has corrupted part of your data inside the data area, it doesn't do any additional harm. So don't bother using --fail and --remove on the member devices. Phil -- 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
