From: Christoph Hellwig <hch@lst.de>
To: Nick Piggin <npiggin@suse.de>
Cc: Christoph Hellwig <hch@lst.de>,
viro@zeniv.linux.org.uk, dbrownell@users.sourceforge.net,
agl@us.ibm.com, ebiederm@xmission.com,
linux-fsdevel@vger.kernel.org,
ecryptfs-devel@lists.launchpad.net, jaharkes@cs.cmu.edu
Subject: Re: [PATCH, RFC] add a vfs_fsync helper
Date: Mon, 22 Dec 2008 13:56:22 +0100 [thread overview]
Message-ID: <20081222125622.GA3019@lst.de> (raw)
In-Reply-To: <20081222123534.GE13406@wotan.suse.de>
On Mon, Dec 22, 2008 at 01:35:34PM +0100, Nick Piggin wrote:
> Seems like an improvement.. I've wanted to know, though, what do
> we need i_mutex for? Is it just convention, or is there some good
> reason to have it in generic code?
At least XFS doesn't need it. Same for the filemap_fdatawrite /
filemap_fdatawait which at least for filesystems that want to provide
integrity guarantees is in the wrong place.
This patch is a first one out my work to refactor fsync, and I'm trying
to feed it to mainline in pieces. The next one will be to make sure
nfsd always has a struct file available when calling fsync, but I need
to do some extensive benchmarking. After that we can change the
fsync prototype to drop the dentry paramters, and move the
filemap_fdatawrite / filemap_fdatawait aswell as the i_mutex locking
into the actual methods.
next prev parent reply other threads:[~2008-12-22 12:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-22 9:03 [PATCH, RFC] add a vfs_fsync helper Christoph Hellwig
2008-12-22 12:35 ` Nick Piggin
2008-12-22 12:56 ` Christoph Hellwig [this message]
2008-12-22 13:00 ` Nick Piggin
2008-12-22 13:25 ` Al Viro
2008-12-22 20:11 ` [PATCH] " Christoph Hellwig
2008-12-22 20:42 ` David Brownell
[not found] <200812220143.29375.david-b@pacbell.net>
2008-12-22 16:07 ` [PATCH, RFC] " Alan Stern
2008-12-22 16:16 ` Christoph Hellwig
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=20081222125622.GA3019@lst.de \
--to=hch@lst.de \
--cc=agl@us.ibm.com \
--cc=dbrownell@users.sourceforge.net \
--cc=ebiederm@xmission.com \
--cc=ecryptfs-devel@lists.launchpad.net \
--cc=jaharkes@cs.cmu.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.