LVM1 to LVM2 plans for FC2

[Alexandre Oliva]

On Feb  9, 2004, Paul Jakma <paul at dishone.st> wrote:

> On Mon, 9 Feb 2004, Alexandre Oliva wrote:

>> I just find it too much of a hassle to keep it all out of /. 

> Only if your system lacks decent volume management :)

Well...  See, creating/renaming/removing one LV is still easier than
doing it on 3-5 LVs.  No matter how decent such management is.

> Well, how often do you do install's?

I never upgrade, and I try to test every test release and then some
more.  So, it's pretty often.

> If you're going to be installing new stuff every now and then, 
> seperate partitions again helps - you can "shuggle" stuff around 
> until you have enough contigious partitions free for your new 
> install. And again, LVM helps here: pvmove.

But see, you don't need the space to be contiguous, that's one of the
beauties of LVM.  You can do live pvmove and optimize the system for
whatever use you like (see LVreorg in my home page).  Having to use
separate root partitions would be sort of a nightmare.  Really, even
if I were to keep separate root filesystems, I'd probably still want
to use LVM for them.

> Similarly, if you have /var/tmp/ or /var/lib/cache or whatever on 
> it's own LV, its trivial to unmount that and shrink it (if it has 
> some extra space) if needs be, eg in order to give that space to 
> /var/spool/mail :)

Yeah.  I can tell you like having lots of separate filesystems, and
this is surely suitable for the install once and then upgrade.  It's
not all that convenient for my frequent installs from scratch though.
Besides, these machines are pretty much single-user anyway, and I can
afford to bring any of them down for maintenance at any time.  It's
just my personal home office anyway.

> INBOX (ie /var/spool/mail) - you might find the /var/spool/mail is
> full, while you have many gigs free in your /home LV.

Well, for one, /var/spool/mail is a soft link to a directory in a huge
filesystem for me.  Ditto for mqueue.  Such that, when I do a full
install, I don't lose mail spool or queued mail.  And I've got
kickstart scripts that set these links up.

>> fragmenting the root filesystem into multiple partitions tends to
>> generate additional hard disk head movement.

> Well, mostly static partitions shouldnt fragment really.

I'm talking about fragmenting data across multiple partitions.  If you
install a package onto a single filesystems, odds are that all of the
data files, libraries and binaries will be close to each other in the
disk.  But if you have say libs in one partition, binaries in another,
config files in another and data files in yet another, there's going
to be a lot of disk heads movement that you could have saved by using
a single filesystem.

> Optimising volumes to best areas of disk is something I doubt any
> does any more :)

Because filesystems tend to do it for you, to a point.  But by
breaking filesystems up into small pieces, you stop it from helping
you.

> (nearly all my files live on NFS anyway, and then on RAID5 arrays.)

Well, we all know how slow RAID 5 is.  I've recently moved most of my
data to RAID 1 + LVM, and performance has improved significantly.
I only keep multi-media, seldom modified data in RAID 5, just to save
a few hundred GiBs I'd waste with RAID 1.


All that said, there's a lot of room for personal preferences and for
different install/upgrade strategies.  I'm probably jumping out of
this thread for now :-)  Thanks for your insights.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer