In <[EMAIL PROTECTED]>, Shaun Dwyer <[EMAIL PROTECTED]> typed:
> Mike Meyer wrote:
> > [SWAG follows]
> I Disagree.. it will make a difference. If you partion /var near the
> beginning of the disk (the fastest part - outer tracks) it will force
> all the stuff in /var (being logs and stuff) to live at the faster area
> of the disk.
That could well be - after all, this is all just idle speculation. But
then you're seeking all over the disk looking for the data that's
being used by the processes that are writing to the log. Which is
worse?
> im sure there are several other reasons to make seperate
> partitions. Off the top of my head: stop file systems from filling
> up if you have a process dumping large ammounts of data some where
Yup, but we're talking about two stable file systems - / and /usr -
and the log file system /var. Letting / and /usr fill up is nearly
harmless - you can lose the password file on / if someone tries to
change it - so combining those three so that /var has the extra space
means you are less likely to run out of space on it, and at minimal
risk. If you have a system where passwords are changing frequently and
there's a lot of activity on /var, the risk might be higher.
> if one file system is corrupted, you dont lose
> _everything_. Discounting the potential pefformance benefits, these
> two reasons alone should be enough to create seperate file systems.
When was the last time you saw a file system so corrupted it couldn't
be recovered? Modern file systems - at least on the Eunices I work
with - are sufficiently robust that the risk involved isn't worth the
extra headaches created by having extra partitions.
Generally, the valid reasons for splitting file systems are
administrative or physical. Physical because you've got them on
different spindles, and administrative because you're treating them
differently: different backups, different mount permissions, different
upgrade paths, different exports, different owners, or something along
those lines.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message
