Messages in this thread | | | Subject | Re: Status of fsync() wrt mail servers | From | Matthias Andree <> | Date | Fri, 12 Sep 2003 02:22:15 +0200 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |