On 05/02/2017 07:40 AM, Peter Rajnoha wrote:
On 05/01/2017 06:35 AM, NeilBrown wrote:
On Fri, Apr 28 2017, Peter Rajnoha wrote:
Then mdadm opens the devive, clears any old content/signatures the data
area may contain, then closes it - this generates the third event -
which is the "synthetic change" event (as a result of the inotify WATCH
rule). And this one would drop the "not initialized" flag in udev db and
the scans in udev are now enabled.
Nope, it would be incorrect for mdadm to clear any old content.
Sometimes people want to ignore old content. Sometimes they very
definitely want to use it. It would be wrong for any code to try to
guess what is wanted.
The mdadm is not going to guess - it can have an option to
enable/disable the wiping on demand directly on command line (which is
also what is actually done in LVM).
I know the anaconda team keeps pushing for the nonsense of being able to
wipe drives on creation. It is wrong, it is broken, and it is not going
to happen.
Otherwise, if mdadm is not going to wipe/initialize the device itself,
then it needs to wait for the external tool to do it (based on external
configuration or on some manual wipefs-like call). So the sequence would be:
1) mdadm creating the device
2) mdadm setting up the device, marking it as "not initialized yet"
4a) mdadm waiting for the external decision to be made about wiping part
4b) external tool doing the wiping (or not) based on configuration or
user's will
5) mdadm continuing and finishing when the wiping part is complete
I expect mdadm to return only if the device is properly initialized
otherwise it's harder for other tools called after mdadm to start
working with the device - they need to poll for the state laboriously
and check for readiness.
What defines readiness? Some believe a raid1 array must be fully
assembled with all members, other setups are happy to have one running
drive in place.....
4a/4b in your list here once again has no place in mdadm. Please kindly
tell the anaconda team to go back and handle this properly instead.
Jes
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
