[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: transports directory
On Thu, 6 Jul 1995 Nicholas_Briggs.PARC@xerox.com wrote:
> I haven't found the disk activity to be a problem, handling 30-40 K messages
> per day on a SPARCStation 2, with an old slow CDC disk as the postoffice
> (that's the only thing on the disk).
People are having problems with 100,000+ messages per day. See the
mailing list archives.
> I value having the data stable in the file system -- it makes recovery
> relatively easy, and reliable (although my gateway has been up with service
> uninterrupted for 92 days now). If there are errors in recovery I would like
> to make sure it errs on the side of double delivery rather than missed
> delivery, but I would be upset if I always got one or more double deliveries if
> the system rebooted. If state is being maintained in memory (on socket
> buffers, in in-core tables, or whatever) I would be suspicous. If it's being
> maintained on disk too, then you haven't helped the I/O problem much.
The message control files in the scheduler channel directory are merely
just links to files in tranport/* Under my proposal, the scheduler
could simply read incoming message control files from
$POSTOFFICE/scheduler and move them to $POSTOFFICE/transport were they
could be updated by the various transport agents exactly as before.
Basically, all that would be eliminated would be the management of the
channel directories in scheduler/* (automatic creation and deletion, etc).
This would not alter Zmailer original idea of using message control
files as a kind of shared memory. They would just only exist in one place.
> You say,
> "Zmailer saves the message file in
> the public directory, then moves it the router directory, then the router
> moves it to the queue directory and writes a control file in the
> scheduler directory. The scheduler moves the control file into a channel
> directory and makes a link into the transports. As you can see, a fair
> bit more disk activity."
> but I think this is not a significant fraction of disk activity
> compared to the reading and writing of the control files, setting/clearing the
> per-recipient lock flags, and writing/reading the message data files, doing
> database lookups, etc..
Yes, Sendmail has the "rewrite after n deliveries" option for use with
messages that have many receipents. It does speed things up, but if
there is a crash after delivering to some of the receipents, some will
get duplicates.
> If you have time, you might try taking a quiescent system, and trace all the
> zmailer processes, then deliver a message to it, and watch it deliver the
> result. A characterization of the per message I/O, and per recipient I/O
> would be informative, and could provide the basis for an informed decision
> about where to spend effort.
Good idea.
However, I'd like your comments on the following:
If the scheduler was re-written, would you agree that simpler scheduler
queue management should be used?
Tom