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