[CentOS] CentOS 4 Software Raid1 questions

Wed Apr 27 18:28:55 UTC 2005
Aleksandar Milivojevic <amilivojevic at pbl.ca>

Les Mikesell wrote:
> On Wed, 2005-04-27 at 10:44, Aleksandar Milivojevic wrote:
>>You'd need to resize file systems after you import partitions into MD. 
>>An e2fsck/resize2fs would take care of that.  Do an "fsck -f /dev/md0" 
>>(for example).  It will complain that information in superblock is wrong 
>>(partition size fsck sees is smaller than what it found in superblock). 
>>  Just answer "no" to abort question.  After you did fsck, you need to 
>>do "resize2fs /dev/md0".  Repeat for all md devices you created.
>>For above, the file systems should be either unmounted, or mounted read 
>>only.  The best thing to do is to boot from CD into rescue mode, and do 
>>all job from it.
>>The reason is that MD uses couple of last blocks for metadata 
>>information, and that space is no longer usable for file system data. 
>>So your /dev/md* metadisks will be slightly smaller than partitions you 
>>created them on.
> What happens if existing files are on these blocks before you
> convert?

I've no idea what happens in this case.  I guess fsck should complain 
loud and clar if something like this happens, and you'll probably loose 
files that used those blocks.

>>When you are creating mirrors, make sure you list devices in right 
>>order.  Data is always copied from first disk you specify to second 
>>disk.  If you get them the wrong way around, you loose data.
> Another approach that might be safer is to create a 'broken' mirror
> first by specifying the 2nd device as 'missing'.  Then you can build
> a filesystem on the md device and mount it somewhere and copy the
> files over from the existing partition.  Then unmount the old partition,
> remount the raid device in its place (adjusting /etc/fstab to match)
> and use mdadm to add the old partition into the new raid, which will
> hot-sync it to match the new setup.

Yes, that might be safer approach nowdays.  In the old days, it was not 
possible to create "broken" mirrors.

>>There are some rather good HOWTOs on this question (with much longer, 
>>detailed and better descriptions of migration process).  Use the Google 
> I looked for this and found lots of info on building RAIDs but none
> about preserving an existing filesystem while converting to a mirror.
> Can you provide a link or a good search term to pick that up?

For example, "linux raid howto resize2fs" will get you to the following 


It describes the "old" way of creating RAID devices (using /etc/raidtab 
file and mkraid command).  However, information is still usable (simpy 
use mdadm instead of raidtab/mkraid).

> I have noticed that after syncing the mirrored drives, you can split
> them and mount a single drive from it into another machine without
> making an md device first.  (For example, if one part is on a
> USB/firewire drive, you can plug it into a different machine and mount
> the /dev/sda? partition it becomes.) However, I don't know if this is
> harmful or not.  Does anyone know if, after running a while in this mode
> it will still work correctly if detected as an md? device (with or
> without resyncing to a partner)?

Sure thing.  It is "safe" to use submirror that way, since file system 
does not use partition size to determine how much of the partition it 
can use.  It uses size that is stored in the file system superblock. 
The only check it does is that file system size is smaller or equal to 
partition size (which is the case here).  Actually, this is what happens 
during each boot.  The boot partition is accessed directly to load 
kernel and initrd, since md devices do not exist until raid* drivers are 
loaded and initialized.  That is why boot partition can also be simple 
non-striped RAID1.

However, it might not be safe to plug submirror back if you simply 
unplug one of the submirrors.  MD metadata stored at the end of each 
partition is used to automatically detect and assemble arrays when Linux 
kernel boots.  The kernel will find that it has both submirrors present. 
  It will also detect that something is not quite right because time 
stamps (and probably some other info) stored in metadata on those two 
partitions doesn't match.  What exactly the kernel will do, and what 
submirror it will consider as valid, I don't know (probably the one with 
most fresh timestamps).  I also don't know if kernel will start 
automatically resyncing "invalid" submirror in this case.

On the other hand, if you used mdadm to fail and then remove submirror 
prior to unplugging it, it should be noted in the metadata and it should 
be safe to reconnect it.  But I'm not 100% sure.  After you reconnect 
submirror, you'd use mdadm to readd that submirror.

Aleksandar Milivojevic <amilivojevic at pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7