anaconda with lvm default

[Michael Honeyfield]

I am just curious the reasoning behind using lvm as the default partitioning method in the anaconda version shipped with FC3.

I have been looking through the change logs and past mailing lists, but I have not seen any reasons or comments indicating the whys...

Any comments would be great

Thanks

Mike

[Matthew Miller]

On Sat, Mar 12, 2005 at 02:49:45AM +1300, Michael Honeyfield wrote:
> I am just curious the reasoning behind using lvm as the default
> partitioning method in the anaconda version shipped with FC3.

LVM is good.

[Chris Lumens]

> I am just curious the reasoning behind using lvm as the default partitioning method in the anaconda version shipped with FC3.
>
> I have been looking through the change logs and past mailing lists, but I have not seen any reasons or comments indicating the whys...

Well I got to this party after the decision to use LVM for everything
had been made, but I can share my reasons for why I think it's a good
idea.

First, it frees us from a lot of the disklabel constraints.  We don't
really have to worry about four partition limits and extended partitions
and all that junk if we can just make one big LVM blob and cram a bunch
of partitions in there.  So that makes it more flexible for people who
want the really crazy partitioning schemes.

Second, it's nice to have fewer cases to deal with in the partitioning
code.  If we know everyone's got LVM, it means there's less we have to
take into account.  Of course right now, everyone doesn't have LVM.  But
hopefully years down the road, everyone will.  :)

There are probably more but these are the two that immediately popped
into my head.  Personally, I find LVM to be more flexible and getting
used to it now on my own machines means I'll know how to use it when I
finally get that giant disk array set up at home.

- Chris

[Peter Jones]

On Fri, 2005-03-11 at 11:04 -0500, Chris Lumens wrote:
> First, it frees us from a lot of the disklabel constraints.  We don't
> really have to worry about four partition limits and extended partitions
> and all that junk if we can just make one big LVM blob and cram a bunch
> of partitions in there.  So that makes it more flexible for people who
> want the really crazy partitioning schemes.

Yeah, that's a useful property, but even without details of how
partition tables work and whatnot, there's a huge advantage. I think the
biggest gain is that it largely obviates the need to move files around
when you're adding disks.  That is, the old scenario is:

/home fills up
add disk
boot single user
fdisk
mke2fs /dev/hdz1
mount /dev/hdz1 /tmp/home/
cp -avl /home/ /tmp/home/
wait several hours
backup /home someplace else
wait several hours
rm -r /home/
umount /tmp/home/
fix fstab
mount /home
telinit 3

Whereas with lvm the script is more like:

/home fills up
add disk
boot single user
fdisk
pvcreate /dev/hdz1
vgextend /dev/VolGroup00
mount / -o remount,ro
lvextend -i 250g -r /dev/VolGroup00/LogVol01
mount / -o remount,rw
telinit 3

(I haven't tried it this week, and obviously I've left out lots of minor
details, but that's essentially the method)

Not having to move files around is obviously a significant gain.