5

I have two hard drive partitions, which I have combined into a RAID1 using mdadm, and created an ext4 filesystem on the resulting device.

When I mdadm --zero-superblock the two partitions, and re-create the RAID, then the original ext4 metadata is magically preserved.

Why is that?

And how can I tell mdadm to give me a truly new, uninitialised MD?


Details

How I create the RAID1 and file system:

ls /dev/sdc2  # partition 1
ls /dev/sdd2  # partition 2
mdadm --create --run --verbose /dev/md1 --level=1 --raid-devices=2 /dev/sdc2 /dev/sdd2
mkfs.ext4 -L mylabel /dev/md1

Wipe RAID1:

mdadm --stop /dev/md1
mdadm --zero-superblock /dev/sdc2
mdadm --zero-superblock /dev/sdd2

Recreate RAID1:

mdadm --create --run --verbose /dev/md1 --level=1 --raid-devices=2 /dev/sdc2 /dev/sdd2

Display device information (note wipefs without the -a flag doesn't wipe anything but just shows info):

# wipefs /dev/md1
offset               type
----------------------------------------------------------------
0x438                ext4   [filesystem]
                     LABEL: mylabel
                     UUID:  3d230d31-fb82-46ef-a4e0-e9473e05825c

LABEL: mylabel shows that the ext4 label "survived" the mdadm superblock wipe and RAID recreation.

How can that be?

I thought that after a superblock wipe and recreation, mdadm is supposed to present me with a "clean" view of the device (i.e. all zeros), unless a flag is given that turns that off (such as --assume-clean, which I haven't given).

3 Answers 3

9

Because zero-ing the mdadm superblock only removes the metadata that describes the raid array, it doesn’t remove information about what is actually on the rest of the disk. This is actually a good thing, as it means you might be able to recover a volume when the array itself won’t assemble for some unfortunate reason.

And to be clear: because you’re creating the array using volumes and not whole-disk, the partition table isn’t touched by mdadm, so zero-ing the raid superblock isn’t going to affect the drive label nor the partition structure.

8
  • I suggest you add something to your answer that responds to what the second question was effectively: "How do I start fresh?" I suspect that 'dd if=/dev/zero of=/dev/sdc2' and 'dd if=/dev/zero of=/dev/sdd2' would do the trick, for example (you can probably get something much faster that just clears enough to fool filesystem auto-detection.) May 9, 2018 at 3:03
  • @Slartibartfast yeah missed that part. May 9, 2018 at 3:04
  • A few questions: 1) If zeroing the superblock does not have any effect on what reads return from the RAID, then data from which of the two devices will reads return? And given that mdadm immediately starts filling the drive with zeros after creation in the initial scrub, does it mean that within the first couple of minutes, I can read arbitrary data from (one of) the disks, and a few minutes later I will read zeros? 2) I'm not sure about what you say in the "to be clear" part. The ext4 LABEL: mylabel should surely reside within the boundaries of the raid device, right? continuing ...
    – nh2
    May 11, 2018 at 2:02
  • So I'd expect LABEL: mylabel to be probably somewhere at the beginning of /dev/md1. That's why I'm not sure why you mention "the drive label" or "the partition structure". And of course 3) how can I tell mdadm to return "fresh" data (zeros)? dding the whole 10TB drive takes awefully long and mdadm must certainly know which areas are untouched since the creation (as it knows what to scrub in the initial scrub).
    – nh2
    May 11, 2018 at 2:05
  • @nh2 I think there’s some misunderstanding. Zeroing the superblock isn’t having an effect on reads of the volume or partition table because you’re not altering that data when you create or destroy the raid device. May 11, 2018 at 7:01
0

Have yet to see a definitive answer to "remove raid metadata completely?"

here's mine (snippet of raid creation script when previous RAID detected):

DISK=drive with partition (eg: /dev/sdc3)
DRIVE=drive without partition (eg: /dev/sdc)
DRIVE_SECTORS=$(fdisk -l $DRIVE | grep Disk | grep sectors | cut -f7 -d ' ')
RAID_OFFSET=$(wipefs $DISK | grep linux_raid_member | sed 's/  */ /g' | cut -d ' ' -f2)
wipefs -o $RAID_OFFSET $DISK
# Zero last 4M of DISK
dd bs=512 if=/dev/zero of=$DRIVE count=8182 seek=$(($DRIVE_SECTORS - 8192))

Hope it saves someone else the time it cost me to sort this out.

0

I have try this too, do raid-1 for data cloning. Preserving data after --zero-superblock only can work on metadata=0.90 or 1.0, and I guess this is a bug. Because metadata=0.90 or 1.0 putting the superblock at the end of the device (where 1.1 and 1.2 is putting at beginning), which at the end of the device can be dangerous if you have any auto-activation of the raid contents, and this will desynchronise the array and compromise the data. So after --zero-superblock, I will only use the disk for regular disk and no more raid in same disk in order to preserve data, unless I need to start over and clean everything out.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .