[Sunhelp] Advantages of separate partitions

[dhansen at zebra.net]

 First off, asking a question is cool... but asking for a
debate is a bit rude.
 If you don't see any value in multiple partitions then 
don't use them. No one can be forced to plan for the future
of a system and no single method will every be the perfect
solution to every conceivable implementation. While multiple
filesystems make sense and are beneficial, there are times
when a single filesystem is more appropriate.


Some points in favor of multiple filesystems:

  1m) prevent a user from choking your system by using up
	all available disk space and thereby causing your
        machine to crash.
  2m) prevent log files from doing what a luser in #1 could
	do to your system.
  3m) future upgrades/scalability
     3mA) #3 can be done without even halting the system in
	hot-swappable type disk environments or systems
        where not all of the drives are currently in use.
  4m) easier to make sane backups 
  

Some points in favor of a single filesystem:

  1s) workstations that will never have significant growth
      1sA) no thought or planning required in layout
      1sB) no cursing when you realize that all that wasted
             space in /var could go to increasing /usr/local
             once you find out that you could be playing
             Quake if only you had a wee bit more space to
             install it.

 This is, by no means, meant to be a comprehensive list...
it's late and these are the more common factors.

 To explain them a little bit. 1m and 2m should be fairly
self explanatory and _should_ offer enough support for the
argument in themselves. But that isn't always the case, so
we go on to 3m and 3mA. 
  So you layed out your multiple filesystem installation
9 months ago and thought that all you would ever need in
/usr/local would be far less than the 300MB that you gave
it. Time goes on and all of those 3rd party apps and your
custom programs have left you with only 3MBs left and you
still have more items on your wish list that you want to 
install. In the "cool" world where you have a hot-swappable
setup you could keep your server (and all of its services)
running, plug in a new drive, umount /usr/local and either
remount /usr/local onto the new drive and be done with it,
leaving extra space on the original drive to be used for
something else or use something like disksuite and make a
new filesystem that spans the original segment of the old
disk and the new disk and then mount that spanned filesystem
as the new and improved /usr/local (also, external drives
would serve the same uptime-saving-purpose here). This
cannot be done with a single monolithic filesystem. The 
best that you could do is take the entire machine down,
put in a drive of sufficient size that you believe will
not be outgrown _this_ time and hope for the best and
hope that your business didn't lose too much money while
those (hopefully not) critical systems were down. The worst
that you could do is try to keep everything where it is,
add another drive and do something like make a symlink from
/usr/local to the mount-point for the new drive and wait
for those programs and/or installations that break under
this kind of a kludge.
  As for 4m... a combination of multiple filesystems and
seperate directories (like /usr/local or /opt for any
applications that have to live outside of the users home
directories and are not part of the OS installation) are
a 'must have' for any admins' sanity. Use something like
ufsdump (file system dump) to dump just those filesystems
that need to be backed up and in the frequency that they
need. Backup the static portions of the base OS fs's once
a month or so, backup your other filesystems in varying
frequency depending on how often they are likely to change
or depending on what your personal, or business, policies
are...or whatever and then comes "restore!". It tends to
take alot longer to have to selectively restore from a 
massive backup. But if you have a system where you have
backups stored on different tapes (because different
areas of the system really only need to be backed up in 
different frequencies) you can grab the applicable tape
and be done alot faster. One good example would be a case
where a secure machine recently had an exploitable app
installed onto it, someone discovered it quickly and hacked
the server. Reinstall your OS fresh (because you also added
some new hardware to the machine since you last backed up
the Solaris OS portions and forgot to update those backups
and you would then have to contend with missing drivers
while trying to calm down your balding-before-your-eyes
executives) and then grab your 'other' backups (going back
to a date before the exploitable-program was installed onto
your system) and do full restores and you're up and running
in a minimal amount of time and then you can go on to 
whatever needs to be done to compensate for any data lost.
  Basically there are tons of real-world, everyday disasters
where this type of structure will save your a** and your
company.


 But there is an argument for single filesystems as well.
If you are working with a hobby machine or a workstation
that isn't a critical system and probably has a small disk
then it's a pain to sit there and try to plan out a
filesystem layout that will best suit it's needs (although
swap should always be a seperate filesystem (preferrably
on a different physical disk)). Who's going to be 
bothered by downtime other than you, the owner? You aren't
going to have your job security risked because you failed
to plan ahead and take every precautionary measure to ensure
that the systems were kept up and running with the _most_
minimal amount of downtime possible. 

david

p.s.- please note that, in this reply:
    filesystem == slice == partition


> Can anyone tell me what advantages there are to having /usr /var
> /export/home on separate partitions?
> I can only think of one compelling reason, to protect the root partition
> from filling up with uncontrolled log files or users' data.
> Other issues such as ease of backup/restore and moving filesystems to other
> disks if necessary are overcome really by the tools that come with Solaris,
> such as ufsdump.
> 
> I'm willing to hear any debate on the utility of the "OBR" (One Big Root)
> Filesystem.
> Regards
> 
> Simon Marko
> Telstra Internetworking Solutions
>