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
>>Luke.
>
> 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
page:
http://www.linux.com/howtos/Software-RAID-HOWTO-7.shtml
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@xxxxxx> Pollard Banknote Limited
Systems Administrator 1499 Buffalo Place
Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
