Re: Best way to achieve large, expandable, cheap storage?

[Gregory Seidman <gsslist+linuxraid@anthropohedron.net>]

On Thu, Oct 20, 2005 at 11:23:30AM +0100, Robin Bowes wrote:
} Christopher Smith said the following on 04/10/2005 05:09:
} >Yep, that's pretty much bang on.  The only thing you've missed is using 
} >pvmove to physically move the data off the soon-to-be-decomissioned 
} >PVs(/RAID arrays).
} >
} >Be warned, for those who haven't used it before, pvmove is _very_ slow.
} 
} I've just been re-reading this thread.
} 
} I'd like to just check if I understand how this will work.
} 
} Assume the following setup (hypothetical).
} 
} VG:
} big_vg - contains /dev/md1, /dev/md2; 240GB
} 
} PV:
} /dev/md1 - 4 x 40GB drives (RAID5 - 120GB total)
} /dev/md2 - 4 x 40GB drives (RAID5 - 120GB total)

You should at least read the following before using RAID5. You can agree or
disagree, but you should take the arguments into account:

http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt

} LV:
} big_lv - in big_vg - 240GB
} 
} Filesystems:
} /home - xfs filesystem in big_lv - 240GB
} 
} Suppose I then add a new PV:
} /dev/md3 - 4 x 300GB drives (RAID5 - 900GB total)

You use pvcreate and vgextend to do so, incidentally.

} I want to replace /dev/md1 with /dev/md3
} 
} I use pvmove something like this:
} 
} # pvmove /dev/md1 /dev/md3
} 
} When this finishes, big_vg will contain /dev/md2 + /dev/md3 (1020GB 
} total). /dev/md1 will be unused.

/dev/md1 will still be a part of big_vg, but it won't have any data from
any LVs on it. You will need to use vgreduce to remove /dev/md1 from the
VG:

# vgreduce big_vg /dev/md1

} big_lv will still be using just 240GB of big_vg.
} 
} I then use lvextend to increase the size of big_lv
} 
} big_lv will now use all 1020GB of big_vg.
} 
} However, the /home filesystem will still just use 240GB of big_lv
} 
} I can then use xfs_growfs to expand the /home filesystem to use all 
} 1020GB of big_lv.

All correct.

} Have I missed anything?

Just the vgreduce step (and removing the physical drives that make up
/dev/md1).

} R.
--Greg