Converting a regular (non-RAID) HD into a (degraded) RAID 1 installation in-place

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear people,

I've been trying to play around with the conversion of a regular
(non-RAID) 2 TB HD that is almost full to "convert it" into a RAID-1
array.

Of course, I have still not played with the real HD, but I am doing
experiments with disk images (mounted as a loopback device) and I am
surprised to find next to no information about this with more than 3
days of searches (or maybe my google-fu is not very good these days).

While it is said to be risky and so on, I want to prevent creating an
empty (degraded) RAID 1 array with a new HD, moving data to this array
from the original drive that I have and, then, plugging the original
drive into the array to see the data copied once more.

Just to make it clear, the HD that want to be part of a RAID 1 array
is *not* a boot device, which means that I don't really care about
GRUB or any other bootloader. It's purpose in life will be to hold
backups (which, in the future, I may reshape when adding more drives,
but not now).

The only reference that I found that mentioned this in-place
conversion was Debian's recipes [0] for mdadm, but it didn't work, as
the original block device (which cointained a pre-populated ext4
filesystem) couldn't be mounted when used in its md format.

Concretely, what I have been doing is:

    mdadm --create /dev/md0 --level=1 --raid-devices=2 --force
/dev/mapper/loop0p1 missing

where /dev/mapper/loop0p1 is just a regular ext4 filesystem. The array
md0 is created and everything in /proc/mdstat looks fine, but the
command:

    mount -t ext4 /dev/md0 /mnt

doesn't work, saying that:

    mount: wrong fs type, bad option, bad superblock on /dev/md0,
               missing codepage or helper program, or other error
               In some cases useful info is found in syslog - try
               dmesg | tail  or so

If my suspicion is correct, the problem seems to be with the md
metadata overwriting some part of the ext4 filesystem. I have made
sure that the partition /dev/mapper/loop0p1 starts at 1MB after the
beginning of the device /dev/loop0 *and* that there is a lot (many
megabytes) of space after the partition, but before the end of the
device.

I have tried metadata versions 0.9, 1.0, 1.1 and 1.2, all with the
same result. I could only see the previous data that I put in the
filesystem when I created an md device with no metadata (that is, with
--build instead of --create), but that's clearly suboptimal and I
would like to avoid that.

The documentation (man md) relating to the position of the metadata
version 1.2 says that the superblock is positioned at "4KB of from the
start of the device", but is that 4KB *before* the start of the device
(in which case the metadata would fit in the hole between the
MBR/partition table and the beginning of the partition) or 4KB *after*
the beginning of the device (which I think would, indeed, mess with
ext4's bookkeeping information).

I would like to understand better this situation and I can provide all
the details (commands) that I tried so far.

Thank you very much for any help,

Rogério Brito.


[0]: http://git.debian.org/?p=pkg-mdadm/mdadm.git;a=blob;f=debian/README.recipes;hb=HEAD

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
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




[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux