LVM + RAID follow up

[john.abreau at zuken.com (John Abreau)]

On Tue, 2006-11-07 at 19:44 -0500, Rich Braun wrote:

> "Derek Atkins" <warlord at MIT.EDU> wrote:
> > I can't be the first person to think about this problem but
> > not want an infinitely increasing number of MDn RAID arrays.
> 
> I think you're expressing concern about something that's really not as much of
> an issue as you think.  If you did an average of one hardware upgrade each
> year, you'd have /dev/md0 through /dev/md9 at the end of a decade.  By then
> the whole approach to the problem will almost certainly have evolved, and the
> tools you seek may very well have developed.  With today's tools, yes, in
> order to shrink down the number of md[0-9] devices back toward 1 or 2 you'd
> have to make a big fs on a new volume and rsync it, might be a few hours of
> shuffling files.  But that's only after quite a few years of continuous
> runtime.

Like I said before, in the LVM layer you can add the new md device
to the PV, slide the filesystem transparently from the old md device 
to the new one, and then remove the old md device from the PV. No need 
to mess with rsync or to copy files at the filesystem level. It's as 
simple as 

    # Add a new RAID device /dev/md4
    vgextend FooVG /dev/md4

    # Move everything from /dev/md2 to /dev/md4
    pvmove -v /dev/md2 /dev/md4

    # Remove /dev/md2 from the VG
    vgreduce FooVG /dev/md2

The "vgextend" adds the new device, the "pvmove" migrates everything 
off the old device and onto the new one, and the "vgreduce" removes 
the old device. You can then delete the old md device and the disks 
it's composed of, then when you replace those disks, you can reuse 
the old md device number. Bingo, no unlimited proliferation of md devices.


-- 
John Abreau / Executive Director, Boston Linux & Unix
IM: jabr at jabber.blu.org / abreauj at AIM / abreauj at Yahoo / zusa_it_mgr at Skype
Email jabr at blu.org / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9
PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.blu.org/pipermail/discuss/attachments/20061107/f13859d6/attachment.sig>