LVM1 to LVM2 plans for FC2

Paul Jakma paul at dishone.st
Mon Feb 9 20:51:37 UTC 2004


On Mon, 9 Feb 2004, Alexandre Oliva wrote:

> Yeah, and /var, etc.

Oh absolutely :)

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

Only if your system lacks decent volume management :)

> I used to arrange things like that back in another life as a
> Solaris sysadmin, but then I'd run out of partitions faster than
> I'd like.  And then, reinstalling things onto a single root
> filesystem is no big deal anyway.  Much simpler than having to
> create a bunch of new root partitions and other LVs just to do a
> fresh install on the same box.

Well, how often do you do install's? The box I'm thinking of
upgrading to 2.6+LVM2 from 2.4 LVM1 hasnt been "installed" since
RH5.1 or there abouts :)

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.

In my experience, the /finer/ grained your partitions are, the easier 
it becomes to rearrange them, as you can be far more selective about 
how you rearrange things.

It also lets you deal with problems far more easily. Eg, it is 
trivial to deal with /var/spool/mail being full if that is on its own 
LV, unmount, resize, remount. However, if it is not, you are screwed 
- you cant unmount /var without taking the machine down to 
single-user mode.

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 :)

Quite handy if you get caught on the hop with respect to system
sizing, or if reality decided not to play with your conceptions of
disk space needs when you installed and partitioned the machine.  
Eg, the ratio of mail users keep in folders in /home Vs in their
INBOX (ie /var/spool/mail) - you might find the /var/spool/mail is
full, while you have many gigs free in your /home LV. 10 minute
outage of IMAP/POP3 and SMTP services while you fix it, (but other
services dont need to go down) IFF you have "fine grained"  
partitions.

> Booting into another installed OS is the easiest way for me, but
> there's always the rescue CD.

I view my root fs as my primary rescue partition. Hence, keep it
small, keep it as RO as possible (ie /etc should be only dir with
regular write activity - try to avoid using ~root for anything other
than static shell rc files.) use the safest, most widely tested fs on
/ (ie ext3, ext2 would be safer, but isnt journalled).

> To enjoy this benefit you *really* need a separate /var too. 

Oh, that goes without saying :)

/tmp should be a seperate fs too obviously. (either it's own
partition or tmpfs).

> And unfortunately a significant number of low-level stuff writes to
> /etc and /dev (lvm and dhcp's resolv.conf munging come to mind)

Yes, but write's will still be quite rare. (esp if you mount with
noatime).

> I've always recommended minimal /boot, user stuff in a separate
> /home or however you want to name it, and the OS stuff in a single
> partition.  It's simple to manage, and is likely to keep the OS
> more efficient in the long run; fragmenting the root filesystem
> into multiple partitions tends to generate additional hard disk
> head movement.

Well, mostly static partitions shouldnt fragment really. Also, if
you're worried about head movement, you can site your most heavily
used partition in the middle of the disk, and at least be confident
that those heavily used files /are/ in the middle of the disk, not
spread across it.  (probably the binaries and libs in /usr for a
workstation). But how much of a worry is this these days? Optimising 
volumes to best areas of disk is something I doubt any does any more 
:) 

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

>  Of course the same goes for a separate /home partition, but you
> really don't want to do without that!

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
	warning: do not ever send email to spam at dishone.st
Fortune:
April 1

This is the day upon which we are reminged of what we are on the other three
hundred and sixty-four.
		-- Mark Twain, "Pudd'nhead Wilson's Calendar"





More information about the devel mailing list