Post by Phillip Bruce<snip text>
Earlier in the thread people seemed to be arguing that lots of
partitions
for /, /var, /usr, /opt, ... somehow made backups easier.
</snip text>
Mike
Mike,
Having separate filesystem make it easier to manage especially when
you have NON critical filesystems
that don't need to have the OS shutdown to repair. Also if you don't
have logging disk fsck won't take
as long to run during the boot up either. I'll still see too many people
put everything under / just because
they think it is easier to backup a single filesytem than it is multiple
filesystems.
I am a firm believer in the OS belongs in /. Applications (e.g. the reason
that you have the OS) belongs elsewhere. Application logs should not write
to / or to /var. The only directory that should be writable to non-sysadmin
users is /var/tmp. On a system where that is subject to abuse, /var/tmp
should be considered for a separate file system or an aggressive tmp cleaner
should be used. /tmp should be tmpfs and should be limited to a smallish
portion of the amount of physical RAM on themachine. Applications (oracle on
a database server, mail spool and mail queue on a mail server, ~ftp on an
anonymous FTP server, logs for centralized syslog server, etc.) belong on a
file system separate from any OS data.
I can honestly say I have never seen downtime on a Solaris box that was a
result of someone filling up the root file system when / and /var were on
the same file system that could have been prevented if / and /var were on
different file systems. I've heard many people say that filling up a file
system can lead to file system corruption. There are most definitely bugs in
the past where this could happen. There are also bugs, however, that the use
of rm or ln at just the wrong time would cause file system corruption. More
likely, however, people are lumping file truncation due to out of block
situations (file system data loss) as file system corruption. If you were to
talk to a file system developer, I would bet they would only classify
conditions of file system metadata loss as file system corruption.
I have an aggregate 1000+ desktops and 800+ servers (SPARC 1 - 25k) in my
experience. I have seen significant amounts of planned downtime because
someone thought that dicing up the OS disks into lots of partitions would be
a good idea. An outage is then planned to perform the rather complicated
process of repartitioning OS disks.
Even with good planning, something often happens to the purpose of the
machine or some other influence causes bloat in one of the file systems. As
an example, consider a typical machine from Sun's line-up when Solaris 8 was
new. Who would think that on that system with 4 - 18 GB disks that you need
to have a huge /var to deal with /var/sadm that grows out of control because
Sun has a monstrocity called the "kernel and apache" patch that grows to
well over 50 MB (uncompressed) and gets revved on an average of twice per
month, starting 2 years after the system was installed? Hope you pick a good
patch to go to, because either you can't save backout data or you will be
patching again (with another 50 MB of backout data) real soon.
The disadvantage of having everything under root is that if you have a
Post by Phillip Brucecorrupted / you'll end up just having
to shutdown the OS to repair it. You only need to do that if / and /usr
has those types of problems the others
you can leave the OS up and running as long you don't have an
application that is using that filesystem. Then it
just a matter of shutting down that app and repairing that filesystem.
Perhaps you are doing something than I am, but I can't think of too many
times where I ran into a corrupted OS file system when I thought that the
best course of action was to try to fix it with the production workload
running. Frankly, if I am running into one file system that is corrupt, this
implies that there may be something going on in kernel data structures or
logic that say that I should probably do a reboot fsck all file systems of
that type, and go looking at the most recent patches for the kernel, that
file system type, relevant block devices, SCSI controllers, etc. to see if
any of the bugs fixed look like what I just saw.
Also too many times I've seen admins that centralize their logs files
Post by Phillip Bruceunder /var/adm directory have /var filesystem that is under /
filesytem and wonder why / filesystems get full and keeps them wondering
why the OS goes to a crawl state and crashes
because of it.
If you have a lot of activity on the partition(s) that your OS is on, you
are patching, running backups, or doing something wrong. That is, even if
someone puts something huge in /var/tmp and fills up /, the overall system
performance should not be impacted - only those things that need to allocate
new blocks in the same partition as /var/tmp may be impacted because the OS
is unable to allocate contiguous blocks or the blocks are distant from the
relevant inode(s).
PLANNING!!! I can't stress how important it is to plan your Operating
Post by Phillip BruceSystem filesystem layout. That benefits your
particular needs. If you can manage separate filesystems then you much
better off and have far less down time than
you will if you have just a single filesystem with everythign on it.
Agreed. Plan to keep strict separation between the OS and the reason you are
running an OS. It will make it easier to know who to page when things go
wrong (sysadmin vs. dba), it will make it so that you can have cookie-cutter
images so that you may have no reason to back up the OS (it looks just like
the flar...), and it will make it much easier when it comes time to migrate
applications to a new system, upgrade/reinstall the OS, use tools like live
upgrade, etc.
Mike
[Non-text portions of this message have been removed]
------------------------ Yahoo! Groups Sponsor --------------------~-->
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/CZFolB/TM
--------------------------------------------------------------------~->
Please check the Links page before posting:
http://groups.yahoo.com/group/solarisx86/links
Post message: ***@yahoogroups.com
UNSUBSCRIBE: solarisx86-***@yahoogroups.com