Re: [tlug] Overloaded mail spool causing memory instability?

[Curt Sampson <cjs@example.com>]

On Sat, 18 Aug 2007, Stephen J. Turnbull wrote:

> Thus, opening a file for append takes a millisecond at most, and only
> a few KB of memory, mostly for buffers.

Assuming it does append that way. Which I'm guessing is the case, but if
there were a local delivery agent using uwimap or something like that,
it could well be different. (For example, there might be some sort of
check to see what the format of the mail file is.)

> By the way, if you don't need to preserve the spam, just stop the mail
> server (typically with something like "sudo /etc/init.d/exim stop"),
> rm the file, and restart the mail server.  If during those ten
> seconds a mail is presented for delivery (to any mailbox), you'll have
> to wait an about extra 15 minutes for it, until the remote MTA retries.
>
> If you do want to preserve the spam, use mv to rename the file.

Why stop the server for rm but not mv? Both have the same effect on the
source directory entry. If mv is fine without stopping, rm ought to be
as well. After all, rm does an unlink on the original name, mv makes a
hard link before doing an unlink on the original name (unless you're
moving the file to a different filesystem).

(Note, I'm assuming FFS or one of its lookalikes (ext2fs, posixy-things,
whatever) here.)

> Both rm and rename are millisecond operations.

In fact, the time doesn't matter, because they are both atomic. At
worst, a few extra e-mail messages are appended to the file after it's
deleted but before the disk storage space is freed, for which we're
quite heiki in this situation.

cjs
--
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
Mobile sites and software consulting: http://www.starling-software.com