All of lore.kernel.org
 help / color / mirror / Atom feed
From: bpm@sgi.com
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-nfs@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [RFC PATCH 0/4] wsync export option
Date: Thu, 4 Feb 2010 12:15:29 -0600	[thread overview]
Message-ID: <20100204181529.GK5702@sgi.com> (raw)
In-Reply-To: <20100204153006.GC22014@infradead.org>

On Thu, Feb 04, 2010 at 10:30:06AM -0500, Christoph Hellwig wrote:
> On Wed, Feb 03, 2010 at 05:44:24PM -0600, Ben Myers wrote:
> > The following series is adds a 'wsync' export option to nfsd.  It is intended
> > to be used on XFS with the wsync mount option.  When you already have a
> > synchronous log there is no need to sync metadata separately.
>
> You don't need the xfs wsync option, as the existing write_inode calls
> or your new fsync calls are doing the same as the wsync mount option,
> just from a higher layer.

Ok, I see that now.  write_inode_now is basically a superset of what we
need.  The important thing is to force the log (which
xfs_file_operations.xfs_file_fsync does do) but not to call
xfs_super_operations.write_inode (via write_inode_now) which eventually
gets into xfs_iflush and takes forever.  We can take forever later-- when
the log is full.  ;)

> The wsync option causes the log to be synchronously forced up to the
> log sequence number of the commit for the metadata operation, that is
> make all the operations affected by it synchronous.  That's exactly
> what we'll do using fsync (actually right now we force the whole log,
> but I have a patch to optimize it to only force nuntil the last commit
> lsn), and approqimately the same as we do using write_inode, just a
> lot less efficiently.

Rather than having X number of synchronous log transactions written
separately as with wsync you have X number of log transactions written
out together in one go by vfs_fsync (if datasync==0).  That should be
faster than wsync.
 
> > Curious to hear if this is a reasonable thing to do.  Suggestions
> > welcome.
> 
> I think it's reasonable.  What might be even better it to have an
> export operation call out into the filesystem so that we can force
> wsync and not let nfsd deal with it at all.  There is a fair chance
> that the filesystem can do the sync more efficiently.

Trond also suggested an export_operation and I think it's a good idea.
I'll explore that and repost.

Thanks,
	Ben

WARNING: multiple messages have this Message-ID (diff)
From: bpm@sgi.com
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-nfs@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [RFC PATCH 0/4] wsync export option
Date: Thu, 4 Feb 2010 12:15:29 -0600	[thread overview]
Message-ID: <20100204181529.GK5702@sgi.com> (raw)
In-Reply-To: <20100204153006.GC22014@infradead.org>

On Thu, Feb 04, 2010 at 10:30:06AM -0500, Christoph Hellwig wrote:
> On Wed, Feb 03, 2010 at 05:44:24PM -0600, Ben Myers wrote:
> > The following series is adds a 'wsync' export option to nfsd.  It is intended
> > to be used on XFS with the wsync mount option.  When you already have a
> > synchronous log there is no need to sync metadata separately.
>
> You don't need the xfs wsync option, as the existing write_inode calls
> or your new fsync calls are doing the same as the wsync mount option,
> just from a higher layer.

Ok, I see that now.  write_inode_now is basically a superset of what we
need.  The important thing is to force the log (which
xfs_file_operations.xfs_file_fsync does do) but not to call
xfs_super_operations.write_inode (via write_inode_now) which eventually
gets into xfs_iflush and takes forever.  We can take forever later-- when
the log is full.  ;)

> The wsync option causes the log to be synchronously forced up to the
> log sequence number of the commit for the metadata operation, that is
> make all the operations affected by it synchronous.  That's exactly
> what we'll do using fsync (actually right now we force the whole log,
> but I have a patch to optimize it to only force nuntil the last commit
> lsn), and approqimately the same as we do using write_inode, just a
> lot less efficiently.

Rather than having X number of synchronous log transactions written
separately as with wsync you have X number of log transactions written
out together in one go by vfs_fsync (if datasync==0).  That should be
faster than wsync.
 
> > Curious to hear if this is a reasonable thing to do.  Suggestions
> > welcome.
> 
> I think it's reasonable.  What might be even better it to have an
> export operation call out into the filesystem so that we can force
> wsync and not let nfsd deal with it at all.  There is a fair chance
> that the filesystem can do the sync more efficiently.

Trond also suggested an export_operation and I think it's a good idea.
I'll explore that and repost.

Thanks,
	Ben

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2010-02-04 18:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-03 23:44 [RFC PATCH 0/4] wsync export option Ben Myers
2010-02-03 23:44 ` [RFC PATCH 1/4] Add 'wsync' " Ben Myers
2010-02-03 23:44 ` [RFC PATCH 2/4] Add datasync argument to nfsd_sync_dir() Ben Myers
2010-02-03 23:44 ` [RFC PATCH 3/4] If 'wsync' call vfs_fsync() instead of write_inode_now() Ben Myers
2010-02-03 23:44 ` [RFC PATCH 4/4] If 'wsync' pass datasync=1 to vfs_fsync() Ben Myers
2010-02-04 15:19   ` Christoph Hellwig
2010-02-04 17:20     ` bpm
2010-02-04 18:30       ` Christoph Hellwig
2010-02-04 18:38         ` Trond Myklebust
2010-02-04 18:40           ` Christoph Hellwig
2010-02-04 18:52             ` Trond Myklebust
2010-02-03 23:47 ` [ RFC PATCH 5/4 ] Add wsync export option to nfs-utils bpm
2010-02-03 23:58 ` [RFC PATCH 0/4] wsync export option Trond Myklebust
2010-02-04 15:21   ` Christoph Hellwig
2010-02-04 15:30 ` Christoph Hellwig
2010-02-04 15:30   ` Christoph Hellwig
2010-02-04 18:15   ` bpm [this message]
2010-02-04 18:15     ` bpm
2010-02-04 18:39     ` Christoph Hellwig
2010-02-04 18:39       ` 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=20100204181529.GK5702@sgi.com \
    --to=bpm@sgi.com \
    --cc=hch@infradead.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=xfs@oss.sgi.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.