Vivek Goyal <vgo...@redhat.com> writes: > Ok, I am playing with it more and trying to understand it better.
I wrote a test case for this: https://github.com/mvollmer/docker-storage-setup/blob/664a1fbf4f9683778081f9827737e84af7a8bc8f/tests/002-no-pvcreate-prompts-for-stale-fs-signatures > So If I create a partition say /dev/sdb1 and create "mkfs.xfs /dev/sdb1" > and later remove partition /dev/sdb1 (which will leave xfs signature > somewhere around 2048 sector by default) and then pass disk /dev/sdb > to pvcreate, it only complains about dos signature (if it is present). It > does not care about if there is any other signature later in the disk. Correct. (But d-s-s will have rejected /dev/sdb already earlier, because of the partition table on it.) > I guess may be wipefs has internal defaults and that xfs signature > does not even appear in the list. But if I re-create partition table > and do "wipefs /dev/sdb1" suddenly that xfs signautre becomes visible > to wipefs as well as pvcreate and now pvcreate refuses to create > partition. > > IOW, if wipefs finds a signature, pvcreate will complain otherwise > it will not. And as dss creates a partition on disk, we make that > signature visible to wipefs which was not visible otherwise. > > Even if we do "wipefs -a /dev/sda" on whole disk in the beginning it will not > help because at that point of time wipefs only lists partition table > signature and not xfs signature. So pvcreate will still fail. Correct. My patch did "wipefs -a /dev/sda1" after d-s-s had created the partition for this reason. > So I still feel that by default we need to be defensive and if we find > a signature at any point of time, we bail out. And implement an option > to override this behavior where we will wipe-out/ignore signature > found and continue with the operation. Okay, sounds good. > I had not thought about it much till now. Now you have run into it, good > we are discussing the details now and coming up with a defined behavior. Excellent!
