[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