Re: transports directory

[Nicholas_Briggs.PARC@xerox.com]

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).

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.

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..

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.

					\nick