Date: Fri, 17 Sep 1999 18:02:39 +0200 From: Brad Knowles <blk@skynet.be> To: Dan Nelson <dnelson@emsphone.com> Cc: Thomas Dean <tomdean@ix.netcom.com>, freebsd-current@FreeBSD.ORG Subject: Re: More benchmarking stuff... Message-ID: <v04205536b4081421e68a@[195.238.1.121]> In-Reply-To: <19990917104608.A55059@dan.emsphone.com> References: <v0420551eb407de6b4226@[195.238.1.121]> <v04205525b407f3131c41@[195.238.1.121]> <v0420552bb40800dd5b32@[195.238.1.121]> <199909171505.IAA57153@ix.netcom.com> <v04205535b4080adcb6cf@[195.238.1.121]> <19990917104608.A55059@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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, <blk@skynet.be> 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04205536b4081421e68a>