Re: Found duplicate PV: using /dev/sda3 not /dev/md1

Hi Rainer,

[CC to list added back.  Use reply-to-all on kernel.org lists]

On 06/16/2014 09:53 AM, Rainer Fügenstein wrote:

PT> Your problem is that you are using version 0.90 metadata.  It and v1.0
PT> put the superblock at the end of the member devices, and it cannot be
PT> found if the device size changes.  Plus, the data starts at sector zero,
PT> so if the MD superblock isn't found, the device content is identified
PT> without the raid layer.

If I understand it correctly, the error happened (apart from the
superblock version) because of the reboot(s) before a) md1 was grown
and/or/maybe b) sync was finished.

Probably, but v0.9 arrays are vulnerable to whole-disk vs. partition
misidentification, and should never be used on a partition that
encompasses the end of a disk.

PT> These metadata formats should only be used with boot partitions that
PT> need to be readable without assembling the array.
this was how the centos installer created the raid (with 0.90). will
keep it that way on md0 (which holds /boot and root).

PT> You need to stop /dev/md1 as soon as possible to eliminate the chances
PT> of further corruption.

[root@gateway home]# mdadm --manage --stop /dev/md1
mdadm: fail to stop array /dev/md1: Device or resource busy
Perhaps a running process, mounted filesystem or active volume group?

[root@gateway home]# lsof | grep md1
md1_raid1   461      root  cwd       DIR                9,0     4096          2 /
md1_raid1   461      root  rtd       DIR                9,0     4096          2 /
md1_raid1   461      root  txt   unknown                                        /proc/461/exe

since nothing else than md1_raid1 is accessing /dev/md1, I assume it
is safe to --force --stop?

What is running as process ID 461?  That needs to be killed off, and any
mount involving /dev/md1 stopped.

PT> If you must keep the server online, I recommend the following steps:

big thanks, your strategy is much better than the one I had planned
(and fills some knowledge gaps).

Your situation is the primary reason I recommend LVM.

Phil

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html