[Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem

[Eric Jon Rostetter]

Quoting Timo Sirainen <tss at iki.fi>:

>> It depends on the locking scheme used by the filesystem. Working queue
>> directories (the ones where stuff comes and goes rapidly) is best suited
>> for a local FS anyway.
>
> And when a server and its disk dies, the emails get lost :(

It would appear he is not talking about a /var/spool/mail type queue/spool,
but the queues where the MTA/AV/Anti-Spam/etc process the mail.

For the most part, on machine crash, this will always result in the mail
being lost or resent (resent if it hasn't confirmed the acceptance of the
message yet).  If done with battery backup, the risk is less, but since
most filesystems (local or remote) cache writes in memory, the chances you
will lose the mail is high in any case (if still cached in memory).

I agree that for smaller mail systems, the processing queues
are best on local fs or in memory (memory for AV/Anti-Spam, local disk
for MTA processing).  The delivery queues (where the message awaits delivery
or is delivered) are best on some other file system (mirrored, distributed,
etc).

For a massively scaled system, there may be sufficient performance to
put the queues elsewhere.  But on a small system, with 90% of the mail
being spam/virus/malware, performance will usually dictate local/memory
file systems for such queues...

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin

This message is provided "AS IS" without warranty of any kind,
either expressed or implied.  Use this message at your own risk.