partitioning new installation

Lennart Sorensen lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org
Thu Mar 9 21:45:07 UTC 2006


On Thu, Mar 09, 2006 at 04:08:47PM -0500, wattst-dxuVLtCph9gsA/PxXw9srA at public.gmane.org wrote:
> I'm curious about LVM as I should be doing a reinstall soon.  I understand that
> that LVM maps physical entities to appear as one or many different volumes
> which don't neccessarily reflect the geometry of the physical.  What I don't
> understand is when you say resizing the volumes is easy.  Does it make in
> simpler because you can grow an LVM over existing, formated space?  Or shrink
> it and create a new volume on the newly freed space?
> 
> What I'm really getting at is what has to happen underneath the LVMs.  Do you
> already have to have a fixed chunk formated as an LVM compatible filesystem and
> then build on top of only that?  If I have an NTFS partition and then ext3
> partitions with LVM on top and I want to give some space from NTFS to ext3, is
> that possible?  What steps would be involved in doing that?

The main problem with resizing when usingpartitions is this:

Partition   Start sector   End Sector
1           0              999
2           1000           2999
3           3000           9999

If you wanted to shrink partition 3 and increase partition 2 by 500,
then you have to first shrink partition 3 by 500, then move it to the
end of the device to leave 500 free between partition 2 and 3 and then
expand partition 2 by 500.

With LVM you don't worry about the physical blocks actually used by the
logical volumes (LV) since that is all managed automatically.  You
create some physical volumes (PV) and then create a volume group (VG)
from those PVs.  The PVs can be whole disks, md raid devices,
partitions, or any other kind of block device in linux.  You can
combine any combination of PVs into a VG.  Once you have your VG, you
create LVs inside it of whatever size you want.  Maybe you are not sure
how big you want things, you can leave some unallocated for later
expansions.  If you later want to change a logical volume, since you
don't know or care where the LV physically stores it's blocks, you can
reduce the size of an LV, and gain free space in the VG, and then expand
another LV with some of that free space.  For all you know one LV uses
the odd blocks and another the even blocks, although that is pretty
unlikely.  It doesn't amtter. since LVM maintains the map of which
physical blocks of all the PVs is used to store the blocks of each LV.
It is quite complex internally, but very simple to use.

The ability to make VGs from many devices is also handy for making
things bigger.  For example I am about to add space to a server here, so
I am going to get a pair of 250G drives, setup one partition on each and
create a software raid1 on those.  Then I will run pvcreate on the new
md device, and then use vgextend to add it to the existing VG I have.
Then I will use lvextend to expand the existing LV for the /data
partition I have file shares on, and once that is done, I will use
e2fsresize most likely to resize the ext3 filesystem to fill the new
size of the LV.  So even though I now have two raid1s on different
disks, the LV will span over both of them and appear to the system as a
single large filesystem.  It doesn't matter to the users that it does
this, they just see the filesystem being much bigger now and have more
free space.  I might leave 50G or so unallocated in the VG after
expanding, just to leave room for increasing other things, although most
likely not, since this is the only volume that has ever gotten close to
full.

Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list