Comment 17 for bug 22301

(In reply to comment #15)
> (In reply to comment #14)
> > I'm not sure what dataloss you're referring to, unless you're talking about
> problems with reformatting RAID partitions that hold
> > data, and you don't want to reformat them.

The point is that the installer is capable of recongnizing old RAID and perhaps
the user
wants only to reenable them. So yes.. you don't want to reformat them if not
excplicitly told
to do so.

>
> At present, we have no user interface code for saying "this partition appears to
> be part of an existing RAID set; are you sure you want to use it?" or for
> displaying such partitions in a different way. We should certainly have such a
> UI. Without that UI, though, the RAID configuration screen can't offer
> partitions that appear to be part of an existing RAID set, because it could
> easily cause people to overwrite their existing data with a new RAID by accident.

We also need to remember that we must be able to undo our changes.. see below

>
> > I deleted all partitions and then created RAID partitions on the empty disks.
> Perhaps when a RAID partition is added, it needs to
> > be flagged with something that says "this is an empty RAID partition, so you
> can clobber it".
>
> So, what happens is that, when you delete the partition, the partition manager
> fails to zero the RAID superblock; all it really does is remove the entry from
> the partition table. If you then create a partition starting at the same
> position on the disk, the old RAID superblock will still be in place, and the
> kernel will think that the partition is part of a deactivated RAID set. Your
> /proc/mdstat confirms this:
>
> md0 : inactive hdd1[2]
>
> To work around this, you need to do the following:
>
> mdadm --stop /dev/md/0
> mdadm --zero-superblock /dev/hdd1
>
> It should then be possible (possibly after a reboot to de-confuse parted) to
> proceed to use this as a physical RAID volume.
>
> > Is there something about what I'm doing that makes this thing think that I
> want to keep the data in the volumes?
>
> It's definitely a partitioner bug that it doesn't zero out the superblock when
> the partition is deleted, but with two days to go until the release candidate I
> think I'd rather leave this as "known bug with known workaround" than as
> "probable fix with unknown consequences".
>
> Thanks for your patience!

IIRC the partitioner also offer the option to revert changes. It is possible however
to restore the md superblocks. Their position is always the same as defined by
the kernel drivers as
it is their size.
So ideally we could back them up somewhere before removing the partition and
restore them later
if the user undo's the changes.
These changes can't make breezy. clearly.. so just for reference:
/*
 * If x is the real device size in bytes, we return an apparent size of:
 *
 * y = (x & ~(MD_RESERVED_BYTES - 1)) - MD_RESERVED_BYTES
 *
 * and place the 4kB superblock at offset y.
 */

#define MD_RESERVED_BYTES (64 * 1024)

(from include/linux/raid/md_p.h)

Fabio