Quoting Erik Christiansen (dva...@internode.on.net): > That leaves /var, which I've kept separate for three decades, to obviate > the risk of furious rates of logging fatally depleting /. OK, it takes > longer now, but the principle remains.
Tip (and one man's opinion): On servers, I've long found it useful to hsve /var as an ext2 filesystem (for highest raw performance), with the following mount options: noatime,nodev,nosuid The noatime option further and substantially reduces metadata overhead, another non-trivial boost to system disk performance. The other two are an aid against software mishap and a first-level obstacle against automated system-cracking tools -- there being no legitimate reason for device nodes or SUID binaries on that filesystem. (Depending on your system, you probably want to ensure that /var/lib and /var/spool are served from elsewhere, either separate filesystems of their own or symlinks to trees elsewhere /like to dirs under /home or some such.) > Growth of /tmp was never a problem, as removal of several day old tmp > files was/is a standard cronjob, at least after you've been bitten once. I actually think tmpfs for /tmp is a fine idea, provided (1) you are aware of what'll happen if it balloons, and (2) you're OK with it being backed by volatile storage and aren't surprised by it being empty after reboots including unplanned ones. The speed gain is serious. If nervous about all of /tmp being volatile, you could, e.g., have subdir /var/volatile only mounted as tmpfs. For me, I'm leaning towards all of /tmp being on tmpfs and _no_ swap of any kind on near-future server systems because of intended use of only SSDs, no spinning rust at all. I don't have hard data, but suspect that the wear on SSDs from swap activity is substantial to a degree that outweighs swap's functional utility -- for my use-case, at least. I intend to have a go at a style of operation where running out of physical RAM means the OOM killer gets loose for a while, and see how that goes. The implicity assumption is 'I'll try to avoid that by having enough RAM and not running tasks configured so they're likely to blow up and drive the system into swap.' My metrics say that I haven't been driving into swap, so it's probably a reasonable stance. . _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng