R4z0r said:
This is what I do and still have seperate filesystems.
I only use Linux for servers really and having seperate partitions is a must most of the time. It helps stop a run-away log file/mail spools/various caches taking down the servers.
I long ago re-did the logging on most of our mail/generic servers, the default logging config for most *nix systems is ancient and terribly inefficient, these days I use syslog ng religiously, it lets me configure daily rotation and I've written a perl script that goes through every day and bzip2's the heck out of any log over a day old so my logging footprint is actualy rather small, although I still tend to move logs off of /var, even if the box in question is using a monolthic filesystem (I prefer them elsewhere
)
Our webservers however have all their logs stored on an nfs server with the website data itself, so there's very little in the way of logging actualy going onto the box itself.
Spool files are a pain however, but on most of the mail systems I build these day's they're only used during mail processing, since we've moved to imap based systems storing mail in /var simply isnt practical so mail effectivley only sits in var while it's being processed before being moved to long term storage.
The big problem I find with /var and /tmp is down to things not cleanng up after themselves, this has in the past resulted in them filling up and a whole bunch of things stopping working (this being on our webservers), so all of our new build webservers have monolithic filesystems (and the disk usage is monitored via nagios, just in case).
Then there's the flexability of being able to mount filesystems in different ways (noexec on /tmp for instance) and how much easier life is when you need to re-install.
This is a valid point, although since we use centralised storage we don't have any problems with ireplacable data on server x since the servers hold little more than the software needed to do the job as a result re-installs are normaly done from the ground up (one day I *will* find time to develop an imaging stratedgy)
I also keep a permanent "/snapshot" that stays umounted most of the time unless backups are running.
Since most of our data lives on a nice big nfs server with a dedicated raid array individual boxes are "nukeable" (we can tolerate the time to rebuild a box) so we can happily forego backups on our webservers and sites can be moved from server to server in the event of a failure so funcationality like that is less of a concern for us overall (good idea mind you).
Mind you, I do want to build an imaging stratedgy one day, to make this all easier, but that needs time, something I have precious little of these days
All in all, no, I don't think monolothic filesystems are any good for servers.
Id say it's more a task specific thing, for certian types of server id use monolithic filesystems, others I wouldnt, I think it does overall depend on the potential problems you may or may not have with certian types of server and setups.
).