[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] Running docker-storage-setup from a UI



Vivek Goyal <vgoyal 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!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]