On Thursday 18 December 2008, "M.Lewis" <cajun@cajuninc.com> wrote about 'Re: LVM reorganization': >Thanks Boyd. After reading through it a couple of times, it appears >pretty straight forward. I've done it probably a dozen times now, and it's not hard if you are careful. It also helps to know your way around either fuser or lsof to find (and kill if needed) processes using the areas you are moving to different LVs. Shrinking the LV is probably the most dangerous part. You don't want to have the filesystem be bigger than it's LV at any point. Make *sure* any filesystem on shrunk LVs are good before you start writing data to new or extended LVs. That data might end up over-writing the end of the filesystem! Up to that point (even if you've already allocated the extents with lvcreate or lvextend) you can roll back to your old LVM layout with vfgcfgrestore -- I've screwed up at least twice and had to do that. >Seems like >your method is probably faster without all the overhead of figuring out >the additional packages. I think so. I started using LVM when I went Linux full-time on my desktop and it's been quite useful. I've completely swapped out the disks backing the VG at least once, and I had full use of the system during the pvmove. LVM just makes dealing with storage better. ZFS is supposed to be even nicer, but I'm not entirely convinced and have not tried it myself. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss03@volumehost.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.org/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.