Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I installed F10 in a new 500G disk using the defaults. Bad move
Now I have a big partition with a big Volume Group on it, with a big logical group on it with a big filesystem on it. Bad, bad move, indeed...
Using a Live CD, I manage to resize the filesystem using resize2fs and then, using lvreduce, I shrink the Logical Volume too.
Next step: Resize the Volume Group and after that, reduce the LVM(8e) partition and free space on disk for other partitions.
The big question is: How to reduce a Volume Group ? I already extended a VG adding another PV to it, but this VG has only one PV as big the underlying partition.
I don want't to start over again. I already put my system up to date adn installed a lot of additional software online.
Please, tell me dear Gurus there are light in the darkness ! Enlight me! Show me the TRUE !
cheers !
PS: BTW, I tried "pvresize --setphysicalvolumesize n" but it says /dev/sda2: cannot resize to n extents as later ones are allocated." no matter how BIG is n. What I am doing wrong ?
Last edited by marozsas; 03-17-2009 at 09:08 PM.
Reason: Just in case, please ! - don't post a big TRUE alone in your post.
If you look at the output of "pvdisplay --maps" on your PVdevice you'll probably find that one or more of the LVs are using PEs above the cutoff point you're trying to shrink it to. Mine is like this too:
Code:
root@jupiter:~# pvdisplay --maps /dev/mapper/pvhda2
--- Physical volume ---
PV Name /dev/mapper/pvhda2
VG Name sysvg
PV Size 18.91 GB / not usable 2.42 MB
Allocatable yes
PE Size (KByte) 4096
Total PE 4841
Free PE 1769
Allocated PE 3072
PV UUID oSsu4H-HNk8-TRt0-yXJU-AoDP-82bF-ajtHrQ
--- Physical Segments ---
Physical extent 0 to 1279:
FREE
Physical extent 1280 to 1407:
Logical volume /dev/sysvg/lvswap
Logical extents 0 to 127
Physical extent 1408 to 1663:
FREE
Physical extent 1664 to 1791:
Logical volume /dev/sysvg/lvtmp
Logical extents 0 to 127
Physical extent 1792 to 2303:
Logical volume /dev/sysvg/lvhome
Logical extents 0 to 511
Physical extent 2304 to 4351:
Logical volume /dev/sysvg/lvroot
Logical extents 0 to 2047
Physical extent 4352 to 4607:
Logical volume /dev/sysvg/lvvar
Logical extents 0 to 255
Physical extent 4608 to 4840:
FREE
root@jupiter:~#
As you can see, even though I've only allocated 3072 PE's, they're spread all over the disk.
I've never tried this, but looking at the pvmove man page it looks like its possible to explicitly specify the PE numbers when you move, so assuming pvmove will allow you to move using the same PV for source and destination it may be able to move the PEs down below the point you want to resize too.
DISCLAIMER: THIS IS JUST THEORY, I'VE NEVER TRIED THIS, SO MAKE SURE YOU HAVE A GOOD BACKUP IF YOU DECIDE TO HAVE A GO. YOU COULD LOSE IT ALL
You right !
My LVM setup is such it is using PE all around the PV, so I couldn't resize it.
I didn't try to move PE because they are so many and as you said, there are a big risk to lose my data.
If I have to backup my data first, I decide it is better (in fact, is is more simple, easy) to remove the entire partition and re-create it using a reasonable size and initialize LVM on this partition again and restore the data from the backup.
So, this is what I did do. And it worked !
LVM is good to expand, but not so good to shrink, isn't ?
I can't wait for ZFS or other more advanced FS to come.
If I have to backup my data first, I decide it is better (in fact, is is more simple, easy) to remove the entire partition and re-create it using a reasonable size and initialize LVM on this partition again and restore the data from the backup.
So, this is what I did do. And it worked !
That seems like a sensible approach. I'd have probably done something similar too.
Quote:
Originally Posted by marozsas
LVM is good to expand, but not so good to shrink, isn't ?
I can't wait for ZFS or other more advanced FS to come.
LVM is wonderful, I couldn't live without it, but it's purpose is to allow you to dynamically manage filesystems at the LV level. The PVs are really meant to be mapped onto physical disks which aren't expected to be subject to resizing. On a single OS system, you'd never have a reason to resize a PV. It's only when you start using it on a dual boot PC with its disk partitions that changing a PVs size ever becomes a consideration.
ZFS sounds quite nice, but from what I've read it's not perfect and has its own restrictions and management issues. It also appears that it requires a serious amount of free system memory to stop it running out of buffers and panicking the kernel. According to the FreeBSD guys who have played with it, it's not really recommended for a 32bit system. In contrast, my LVM setup runs nicely on this antique Pentium3 800Mhz with 128MB ram, and that's with the PVs all on LUKS encrypted partitions too.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.