Hi Chuck Munro!

 On 2013.06.10 at 09:42:38 -0700, Chuck Munro wrote next:

> My question is how do I minimize writes to the disk array?  Is it
> possible to significantly reduce disk writes once the host SL6 OS
> has booted up and the guest OS's are running?

There is no real reason to do anything about it; any modern SSD, even
cheapest consumer model won't die from "too many writes" on low-loaded
server (they might die from controller failure or as a result of power
failure, but not from NAND flash chips wear). The special cases where
you should care about wear are loaded SQL databases (they often make all
data go through write buffer of sorts, such as xlog on PostgreSQL or
redo logs on Oracle DB), ZFS ZIL, maybe ext4 with data=journal option
(unsure) and similar cases, where a lot of data is constantly passing
through device.

I'm using SSDs on many servers and, except for the cases above, writes
never exceed typical desktop writes (1-3 TB / year). Any SSD should
endure such writes for many years; if it will die, something else would
be the reason.

So main advice is "don't bother". If you are worried, make sure that SSD
you get provides information about life time writes in SMART; Crucial M4
and various Intel models do that, among many (but some don't).
Then, just check SMART after a few months of usage and stop worrying
after seeing how small write numbers will be.

> The current hard-drive-based box has lots of RAM (8 GBytes) and each

You could mount /tmp as tmpfs, but then again, there isn't much point
for just a virtual host.

> guest has a pretty small footprint, so swapping has never been
> invoked.  So far the current SL6-based firewall pretty well runs
> itself with very little effort on my part, so things like syslog are
> usually not monitored much.  Can the /var filesystem be safely
> mounted from a file server or does it have to be on a local drive
> during bootup?

It can, but it requires tricks. /var/run & /var/lock should be local or
you'll have to hack init scripts.. It's easier to run whole / from NFS
(dracut supports that, though not 100% sure that SL6 version does).

I really advice you not to try this, at least in SL6. Future versions
will have changes to make it easier (/var/run & /var/lock in tmpfs), but
currently, you'd better not.

Anyhow, writing logs hardly contributes to writes on SSD because these
writes are buffered. Even 1 GB of written logs per day is .4 TB of
writes per year. Even cheapest SSDs will handle 10 TB of lifetime
writes, most will more.

> I do let logwatch and logrotate run on the current box (with hard
> drives) but I'm tempted to reduce logging to a bare minimum and
> rotate logs to /dev/null

Well, once logs WERE written, rotating them doesn't contribute to writes
(it usually just renames files).

However, you can do full remote logging - turn off local logs and send
them to remote system, if you really are desperate.


> At this point it's all somewhat academic, but I'd like to consider
> the possibility of reducing heat and eliminating as many moving

I wouldn't expect much difference from heat perspective, unless you are
replacing tons of drives. Under medium load, HDD consumes around 6W,
SSD consumes around 2W. You can win 10 times more of that by switching
to low-power CPU models, for example.

> Your suggestions??

I really believe that you are looking in the wrong direction. There is
no need to do anything on system you described to reduce writes to SSD.
You will prolong theoretical flash life from 200 years to 210 years or
similar (real numbers, on most systems I've seen SSD flash wear is less
than 1% after 2 years of usage), which won't change real life of SSD.

Stop bothering about writes unless we are talking about special cases
like ones mentioned above (I've seen 0.5 PB writes per year for ZFS ZIL,
for example). If any, not using TRIM (and having huge write
amplification) reduces SSD life much more than saving up on writes.
Check out
http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/
or google for "SSD write amplification" if you are curious.

-- 

Vladimir