From: Mike Fedyk <mfedyk@matchmail.com>
To: Matthias Andree <ma@dt.e-technik.uni-dortmund.de>
Cc: reiserfs-list@namesys.com, linux-kernel@vger.kernel.org
Subject: Re: Status of fsync() wrt mail servers
Date: Thu, 11 Sep 2003 10:25:09 -0700 [thread overview]
Message-ID: <20030911172509.GB18399@matchmail.com> (raw)
In-Reply-To: <m3ekynbj3e.fsf@merlin.emma.line.org>
On Thu, Sep 11, 2003 at 02:33:25PM +0200, Matthias Andree wrote:
> Does reiserfs3.6 support dirsync? I thought it was ext3-specific until
> now.
>
That was what I was asking too.
> Please take care to distinguish (file) meta data from directory data.
>
Hmm, it seems to me, that all meta-data relating to the file fsync() was
called on should be sent to the disk and waited for by the call.
> Basically, what we know is that with Linux 2.4, ext3fs, reiserfs and XFS
> will flush all pending transactions (per file system) that were
> requested prior to a synchronous operation (fsync, sync, umount, ...)
> out to disk.
>
> This can heftily bite your back if you're running your MTA's queue on a
> large file system that has other sustained write load (logging, data
> bases, ...).
>
> 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).
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).
Also, if the MTA wasn't running as root, it shouldn't be able to make sync()
affect the entire system. 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?
Mike
next parent reply other threads:[~2003-09-11 17:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20030910002953.C14172@unbeatenpath.net>
[not found] ` <20030910105102.GA535@rahul.net>
[not found] ` <1063192474.18154.355.camel@tiny.suse.com>
[not found] ` <20030910114103.GA26767@rahul.net>
[not found] ` <1063197048.18155.357.camel@tiny.suse.com>
[not found] ` <20030910101821.A15923@unbeatenpath.net>
[not found] ` <20030910213244.GD1461@matchmail.com>
[not found] ` <20030910173343.A16677@unbeatenpath.net>
[not found] ` <20030910234927.GE1461@matchmail.com>
[not found] ` <m3ekynbj3e.fsf@merlin.emma.line.org>
2003-09-11 17:25 ` Mike Fedyk [this message]
2003-09-12 0:22 ` Status of fsync() wrt mail servers Matthias Andree
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030911172509.GB18399@matchmail.com \
--to=mfedyk@matchmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ma@dt.e-technik.uni-dortmund.de \
--cc=reiserfs-list@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).