On 05/06/2017 06:25 PM, Wols Lists wrote: > On 03/05/17 15:13, Peter Rajnoha wrote: >> There's a difference though - when you're *creating* a completely new >> device that is an abstraction over existing devices, you (most of the >> time) expect that new device to be initialized. For those corner cases >> where people do need to keep the old data, there can be an option to do >> that. > > That's not a corner case. If there's old data that's the NORM. I get > what you're after, I'm inclined to agree with you, but the default > should be to DO NOTHING. > > If you want mdadm to mess about with the content of the drives you > should either (a) explicitly tell it to (yes I would like that option > :-), or (b) do it yourself beforehand - dd if=/dev/zero etc etc. As for (b), the "dd" with zeroing all the future mdadm components I'm going to use for an MD device is quite time-consuming operation, mainly for large devices. And we don't need to do that full zeroing at all, what I'm after is to have the wipefs-like functionality directly integrated into mdadm (that functionality is already a part of libbblkid and it's very easy to use it as a matter of fact). With this, we can detect and wipe all signatures that blkid detects. The blkid is used as a primary source of information when processing uevents to decide about further processing. Once we wipe all that blkid can see, we make the device clear for udev processing too and we don't end up automatically activating some old garbage that we don't intend to actually based on these uevent hooks. -- Peter -- 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
