Code review comment for ~raharper/curtin:fix/refactor-preserve-wipe

On Thu, 27 Feb 2020 at 19:58, Ryan Harper <email address hidden> wrote:

> Rebasing this branch and thinking on your comments re: default wipe.
>
> I see what you mean w.r.t wipe defaults. Let me work through the
> scenarios:
>
> For partition creation, we wipe *prior* to creating partitions, explicitly
> at the offset where the partition will be created to prevent "buried
> treasure"
> from being discovered by the kernel as soon as we complete partition
> creation.
>

Oh! OK then :)

> Generally this makes wiping after creating a partition overhead if the wipe
> mode is superblock; If the mode is zero or superblock-recursive; then
> we should follow those instructions and continue to wipe. I dropped this
> last part (avoiding the double superblock wipe, so I'll re-add that).
>

Thanks.

> For composed types (like lvm and raid) it's difficult to wipe before they
> are created ... however, on raid we inspect raid members, and if they have
> existing mdadm metadata we use that to calculate where the data offset
> is and zero that.
>

Well these are a bit different because the tools are a bit more, uh,
assertive about what's going on, or something.

> For raid_handler, we can apply the same skip (only wipe if set and !=
> "superblock"
>
> For LVM, I've not done the work to try to determine where lvm data is
> stored on pvs;
> I'll update this handler to only wipe if it's set.
>

I'm pretty sure that reading from a freshly created logical volume or RAID
will get you zeros irrespective of what was on the disks before (and mdadm
will effectively do an asynchronous wipe: zero anyway aiui) but I guess if
the user explicitly asks for their new raid or lv to have zeros written to
it, we should do that.