From: NeilBrown <neilb@suse.de>
To: "J. Bruce Fields" <bfields@redhat.com>
Cc: linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Peter Staubach <pstaubach@exagrid.com>
Subject: Re: [PATCH 0/2] fix nfsd stable write implementation
Date: Tue, 30 Oct 2012 10:28:33 +1100 [thread overview]
Message-ID: <20121030102833.306e833a@notabene.brown> (raw)
In-Reply-To: <1351285617-20450-1-git-send-email-bfields@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]
On Fri, 26 Oct 2012 17:06:55 -0400 "J. Bruce Fields" <bfields@redhat.com>
wrote:
> From: "J. Bruce Fields" <bfields@redhat.com>
>
> Peter pointed out to me that the nfs server is implementing stable
> writes by setting the O_SYNC flag. I can't see why we couldn't write
> and then sync instead, but I don't know this stuff as well as I should;
> does the following look reasonable to people?
Bruce changed the code to implement stable writes by calling
vfs_fsync_range(). I can't see why we couldn't use O_SYNC instead.
It seems like you are making a change just for the sake of making a change.
Is there some reason that you think a separate 'sync' is more efficient than
using O_SYNC ?
As a general principle, I think it is best to give the file system as much
information as possible to that it can make whatever optimisation decisions
that it wants to.
Setting O_SYNC gives the filesystem more information than not, because it
allows it to change the behaviour of the 'write' request... though I don't
know if any filesystem actually uses the information.
Why the change?
NeilBrown
>
> --b.
>
> J. Bruce Fields (2):
> nfsd: assume writeable exportabled filesystems have f_sync
> nfsd: use vfs_fsync_range(), not O_SYNC, for stable writes
>
> fs/nfsd/vfs.c | 26 ++++++--------------------
> 1 file changed, 6 insertions(+), 20 deletions(-)
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: NeilBrown <neilb-l3A5Bk7waGM@public.gmane.org>
To: "J. Bruce Fields" <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Peter Staubach
<pstaubach-83r9SdEf25FBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH 0/2] fix nfsd stable write implementation
Date: Tue, 30 Oct 2012 10:28:33 +1100 [thread overview]
Message-ID: <20121030102833.306e833a@notabene.brown> (raw)
In-Reply-To: <1351285617-20450-1-git-send-email-bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]
On Fri, 26 Oct 2012 17:06:55 -0400 "J. Bruce Fields" <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
wrote:
> From: "J. Bruce Fields" <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> Peter pointed out to me that the nfs server is implementing stable
> writes by setting the O_SYNC flag. I can't see why we couldn't write
> and then sync instead, but I don't know this stuff as well as I should;
> does the following look reasonable to people?
Bruce changed the code to implement stable writes by calling
vfs_fsync_range(). I can't see why we couldn't use O_SYNC instead.
It seems like you are making a change just for the sake of making a change.
Is there some reason that you think a separate 'sync' is more efficient than
using O_SYNC ?
As a general principle, I think it is best to give the file system as much
information as possible to that it can make whatever optimisation decisions
that it wants to.
Setting O_SYNC gives the filesystem more information than not, because it
allows it to change the behaviour of the 'write' request... though I don't
know if any filesystem actually uses the information.
Why the change?
NeilBrown
>
> --b.
>
> J. Bruce Fields (2):
> nfsd: assume writeable exportabled filesystems have f_sync
> nfsd: use vfs_fsync_range(), not O_SYNC, for stable writes
>
> fs/nfsd/vfs.c | 26 ++++++--------------------
> 1 file changed, 6 insertions(+), 20 deletions(-)
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-10-29 23:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-26 21:06 [PATCH 0/2] fix nfsd stable write implementation J. Bruce Fields
2012-10-26 21:06 ` J. Bruce Fields
2012-10-26 21:06 ` [PATCH 1/2] nfsd: assume writeable exportabled filesystems have f_sync J. Bruce Fields
2012-10-26 21:06 ` J. Bruce Fields
2012-10-26 21:06 ` [PATCH 2/2] nfsd: use vfs_fsync_range(), not O_SYNC, for stable writes J. Bruce Fields
2012-10-26 21:06 ` J. Bruce Fields
2012-10-29 23:28 ` NeilBrown [this message]
2012-10-29 23:28 ` [PATCH 0/2] fix nfsd stable write implementation NeilBrown
2012-10-30 14:07 ` J. Bruce Fields
2012-10-30 20:30 ` NeilBrown
2012-10-30 20:30 ` NeilBrown
2012-11-08 0:20 ` J. Bruce Fields
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=20121030102833.306e833a@notabene.brown \
--to=neilb@suse.de \
--cc=bfields@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=pstaubach@exagrid.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 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.