public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Alex Elder <aelder@sgi.com>
Cc: bfields@fieldses.org, Ben Myers <bpm@sgi.com>,
	linux-nfs@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH 2/2] xfs_export_operations.commit_metadata
Date: Fri, 12 Feb 2010 12:47:07 -0500	[thread overview]
Message-ID: <20100212174706.GB22633@infradead.org> (raw)
In-Reply-To: <1265986006.3201.112.camel@doink1>

On Fri, Feb 12, 2010 at 08:46:46AM -0600, Alex Elder wrote:
> On Thu, 2010-02-11 at 16:05 -0600, Ben Myers wrote:
> > This is the commit_metadata export operation for XFS, including the changes
> > suggested by hch and dgc:
> > 
> > - Takes two two inodes instead of dentries and can assume the parent is
> > always set.
> 
> I alluded to this in my review of the first patch.
> This could be changed considered in a more generic
> sense, "sync one or two inodes' metadata" rather
> than presupposing the two inodes have a parent/child
> relationship.

Or just implement my later suggestion to only pass one inode to the
method and cal in on both inodes.   For the non-create case where
we have only one transaction to deal with fhr first call will take
care of it and unpin the second inode by forcing the log buffer out.
For the create case we need to make sure to call it on the child first
so that we force out the setattr transaction which also forced out the
earlier one.   This keeps the calling convention quite a bit simpler,
and also means we don't have to bother with locking two inodes or lsn
comparisms.

> > - Uses xfs_lock_two_inodes for the ilock.
> > 
> > - Forces the log up to the larger lsn of parent and child.
> > 
> > - Uses XFS_LSN_CMP for lsn comparison.
> > 
> > - Doesn't force the log if nobody had a pincount.
> 
> So if the log doesn't get forced, what causes the
> desired metadata sync expected as a result of this
> call?  (Maybe this is a dumb question.)

Inodes get pinned on transaction commit, and unpinned when the log I/O
for that transaction completes.  If the inode is not pinned this implies
it has already been written to disk, e.g. because we're filling the log
so fast that we need to write out more log buffers in that tiny window
between the metada operation and the commit_metadata call.

> > +		force_lsn = ip->i_itemp->ili_last_lsn;
> > +	}
> > +
> > +	if (force_lsn != NULLCOMMITLSN) {
> > +		error = _xfs_log_force(mp, force_lsn,
> > +				XFS_LOG_FORCE | XFS_LOG_SYNC, NULL);
> 
> You want this here:
>  error = xfs_log_force_lsn(mp, force_lsn, XFS_LOG_FORCE | XFS_LOG_SYNC);

In the XFS tree we do want either

	xfs_log_force_lsn(mp, force_lsn, XFS_LOG_SYNC);

or
	error = _xfs_log_force_lsn(mp, force_lsn, XFS_LOG_SYNC, NULL);

if we care enough about the returned error.  But Ben is working against
the NFS tree which doesn't have that change yet.

We can deal with that by either commiting the old variant to the nfs
tree and then leaving sending Stephen a patch to fix it up in -next,
or just not apply the xfs commit_metadata implementation yet, and wait
for it until both the xfs and nfs trees have hit mainline.

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

  reply	other threads:[~2010-02-12 17:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-11 22:04 [PATCH 0/2] commit_metadata export operation v4 Ben Myers
2010-02-11 22:05 ` [PATCH 1/2] commit_metadata export operation replacing nfsd_sync_dir Ben Myers
2010-02-12 14:23   ` Alex Elder
2010-02-12 17:31     ` Christoph Hellwig
2010-02-11 22:05 ` [PATCH 2/2] xfs_export_operations.commit_metadata Ben Myers
2010-02-12 14:46   ` Alex Elder
2010-02-12 17:47     ` Christoph Hellwig [this message]
2010-02-12 19:56       ` bpm
2010-02-12 20:03         ` J. Bruce Fields
2010-02-12 20:37           ` Christoph Hellwig
2010-02-12 20:35         ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2010-02-17 20:05 [PATCH 0/2] commit_metadata export operation v6 Ben Myers
2010-02-17 20:05 ` [PATCH 2/2] xfs_export_operations.commit_metadata Ben Myers
2010-02-17 23:05   ` Dave Chinner
2010-02-16 21:04 [PATCH 0/2] commit_metadata export operation v5 Ben Myers
2010-02-16 21:04 ` [PATCH 2/2] xfs_export_operations.commit_metadata Ben Myers
2010-02-16 22:07   ` Christoph Hellwig
2010-02-17  0:29   ` Dave Chinner
2010-02-11 19:26 [PATCH 0/2] commit_metadata export operation v3 Ben Myers
2010-02-11 19:26 ` [PATCH 2/2] xfs_export_operations.commit_metadata Ben Myers

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=20100212174706.GB22633@infradead.org \
    --to=hch@infradead.org \
    --cc=aelder@sgi.com \
    --cc=bfields@fieldses.org \
    --cc=bpm@sgi.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox