On Tue, 26 Oct 2004, Scott Ryan wrote: > > You can get some mileage by putting your MTA's temp dir on a shmfs/tmpvs or > > other type of VM filesystem if you're on a different OS to reduce the disk > > i/o cycles. By freeing I/O cycles, the cpus can do more *real* work and > > not wait precious cycles on io time. On a 2.6 kernel, vmstat will tell > > you io-wait time (wa) get a feel for where the bottle neck is. > > This can be dangerous. If your mta stores any mail here for whatever reason > and the box (again for whatever reason) reboots/dies - you lose all that > mail.
Scott makes a very good point. If you don't trust your systems uptime, do not use a vmfs. This for the same reason you don't turn on write-back caching on your raid controller without a battery. I had actually meant the temp directory used by programs like amavis which break the message into file pieces, not the MTA's spool itself. All though, once upon a time we had a controller card which was dying and it kept timing out on IRQs. Moving our mail spool to a vmfs allowed the server to continue to process mail without the long io hang/timeouts until we were able to replace the card (yes, that was a long day). -- Eric Wheeler Vice President National Security Concepts, Inc. PO Box 3567 Tualatin, OR 97062 http://www.nsci.us/ Voice: (503) 293-7656 Fax: (503) 885-0770 _______________________________________________ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users