At 10:46 AM -0500 1999/9/17, Dan Nelson wrote:
> Hmm. But when you're running a mail spool, you _want_ your files to
> get committed to disk, don't you?
True enough. RFC 1123 requires that you *not* lost mail messages
for stupid reasons like fileservers crashing, etc.... You do want
those things written to disk.
> If you've got (guessing) 500 spool
> files sitting in unflushed disk caches and you reboot, those files are
> lost.
Yup. They'd be gone. I guess my question would be how many
messages in the spool that were in the process of being handled could
be held in unflushed caches in memory?
If that's only a few hundred files, and those few hundred files
represent something like only a few seconds worth of mail, then just
how literally are you going to take RFC 1123, and how much mail can a
large operator "lose" before they are violating not only the "law" of
RFC 1123, but also the spirit?
These are tough, real-world questions that I don't really have
any answers for.
This is another reason that I occasionally continue to pester
Eric Allman and Wietse Venema to make changes to their respective
MTAs, so that they at least allow the option of holding open the
connection to the transmitter and not return "250 Ok" until such time
as the mail message(s) have actually been delivered to the mailboxes,
as opposed to just written to spool. This kind of option would allow
wicked-fast things such as running /var/spool/mqueue on a
memory-based filesystem.
Of course, you'd need a timeout and return something like "251
Okay, will spool" and a way to ensure that the spool file for that
message has actually been written to physical disk, although perhaps
this could be left up to the OS and the MTA just uses the standard
system calls to move the file from one directory/filesystem to
another (the source could be an mfs, while the target could be UFS).
Of course, not everyone would want or could make use of an option
like this, but I suspect that the largest sites needing the absolute
maximum performance out of their multiple mail servers would be
*real* happy if this sort of thing were possible.
> Don't NetApps do logging, so if the system crashes, the files are
> recovered from the log?
The log-structured filesystem and snapshots are two advantages
that Network Appliance NFS servers do have.
--
These are my opinions -- not to be taken as official Skynet policy
____________________________________________________________________
|o| Brad Knowles, <[EMAIL PROTECTED]> Belgacom Skynet NV/SA |o|
|o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o|
|o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o|
|o| http://www.skynet.be Belgium |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
Unix is very user-friendly. It's just picky who its friends are.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
