Re: Status of fsync() wrt mail servers

[Matthias Andree <ma@dt.e-technik.uni-dortmund.de>]

Mike Fedyk <mfedyk@matchmail.com> writes:

>> I recently helped one qmail user debug this; the symptom was that the
>> first mail in a burst of mails took 2 seconds to queue, subsequent mails
>> were queued much quicker (70 ms). He was using ext3fs, and had one huge
>> / (root) file system and so the "synch the whole file system" behaviour
>> made his qmail-queue synch *all* his dirty blocks to disk...
>
> Can you be sure the MTA wasn't calling sync() just to be sure (Many MTAs are
> funny in that they think the spool is on a seperate disk and
> filesystem).

For qmail and Postfix I can be. sync(8) isn't remotely useful, because
it's allowed to return before completion.

> fsync() shouldn't be flushing anything not relating to the file it was
> called on (that includes directory entries related to the file also
> IMHO).

It "should", but current implementations on Linux do exactly that: flush
everything. Maybe you've got better luck with BSD softupdates, but
that's going to munch disk I/O big time next time you reboot after a
crash: fsck needed. It runs niced in the background so the machine boots
up, but the box won't satisfy higher I/O demands. Looks like a "ex
duobus malis" game.

> Also, if the MTA wasn't running as root, it shouldn't be able to make sync()
> affect the entire system.

I'd like to see your plans that prevent DoS by local users...

One machine's light load is another one's DoS attack.

> Is there anything that says that sync() can't just flush the user's
> buffers unless you're running as root or with some CAP_ capability?

Does the kernel track "whose dirty buffer is this" (uid_t) at all?

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95