Hi Listers,
I'm very grateful to all the responses to my BaseVol/GuestVol posting;
it's certainly given us a lot to chew on. I think I'm rapidly coming to
the conclusion that this may be just a wee bit over my head. But, I'm
going to keep plugging away, and because I'm certain I'll fall into holes
along the way, may end up learning alot after all.
Thanks very much to all for your insights.
susan
------------------------------
Date: Mon, 25 Jun 2007 11:52:09 -0400
From: "Edmund R. MacKenty" <[EMAIL PROTECTED]>
Subject: Re: BaseVol/GuestVol server for SLES9
On Friday 22 June 2007 16:30, Stricklin, Raymond J replied to :
David Boyes:
>> Probably. Generally accepted practice in the Unix world
>> separates /, /usr, /var, /opt, /home, and /srv (if used) into
>> distinct filesystems.
>
>I'm going to have to respectfully disagree.
>
>Making separate filesystems without understanding the _reasons_ for
>making things separate filesystems is not a long-term recipe for
>success.
And, unfortunately, not making separate filesystems is not a long-term
recipe
for success either. It has always bugged me that the default installation
of
these "Enterprise" distros do not create at least three filesystems and
provide some help screens explaining the purpose and trade-offs involved,
or
at least a few different options for pre-defined filesystem structures.
You're perfectly correct in that the main reason for creating multiple
filesystems is to avoid filling up disks the system needs space on to run.
Of course, how you split things up depends on the purpose of the system.
For
a server, the goal is to keep / from filling up, so at a minimum /, /var
and /tmp should be in separate filesystems. If the system is to be used by
humans, /home should also be separate. If it's a mail
server, /var/spool/mqueue, /var/spool/mail and /var/log might each be on
separate filesystems. If you're going to share DASD, then /usr should
probably be separate. But if you have a workload that chews up space in /,
your system will eventually crash, so you had better move the directory
your
workload is writing into to a separate filesystem.
>> /etc and /tmp are often also split out, but less commonly.
>
>I have never, ever, EVER seen /etc split out, or at least not as
>anything other than a joke. Off the top of my head I can think of at
>least four different varieties of UNIX which won't even boot if you do
>that. Don't do it, it's completely unnecessary and will complicate your
>life in needless ways.
You *can* put /etc on a separate filesystem as long as you make a few files
in
it (passwd, shadow, fstab) available on the root filesystem so that you can
boot to the point of mounting /etc. This is not something you want to do
by
hand, but an automation tool can handle this for you. <shameless-plug>I
make
a Provisioning Expert product that automates the creation of Linux guests
with arbitrary filesystem layouts and manages the sharing of filesystems
between guests for you. It can share almost any part of the directory
structure, even individual files, by cleverly using bind-mounts and
symlinks.</shameless-plug> When I really want to save DASD, I share most
of /etc and make just the few configuration files I'll need to change on a
guest be in a non-shared filesystem (and thus writable). You can do the
same
thing with /dev and /lib if you're brave. ;-)
When setting up filesystems by hand, though, I think the most important
thing
to plan for is flexibility. It's easy to move /home to a separate
filesystem
later on if you find you need to (or even /usr, in single-user mode), but
it's kind of hard to combine a separate /home back into the root
filesystem.
>/tmp is a different story. I've always really liked Sun's approach of
>making it a transient, memory-backed filesystem. It seems that on a
>hypervisor system like VM, where we are using VDISK for swap, there is
>merit in doing the same with tmpfs on linux. We're about to give it a
>shot and see how it works in practice.
I'm ambivalent about /tmp in a tmpfs. Some tools, such as sort(1), use
/tmp
when they would otherwise run out of memory. Sort tries to do as much as
it
can in-memory, but if it runs out, it dumps partially-sorted sub-lists
into /tmp so it can handle more input. Using a tmpfs for /tmp makes this
approach fail. There may well be other tools that do that, but they should
be spooling workload under /var. Come to think of it, sort may be
using /var/tmp, because only system processes are supposed to use /tmp.
User-processes should use /var/tmp. Using a tmpfs for /tmp is just going
to
make it swap more, so for most architectures you might as well put /tmp on
real disk. Under z/VM with VDISK swap, though, it should be more efficient
to put increase your swap size and use a tmpfs because VDISK is faster that
plain DASD. I haven't measured that specifically, though, so I'd be
interested to know what numbers you get from your experiment.
- MacK.
-----
Edmund R. MacKenty
Software Architect
Rocket Software, Inc.
Newton, MA USA
----------------------------------------------------------------------
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
