public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 2/7] xfs: Use delayed write for inodes rather than async
Date: Tue, 26 Jan 2010 09:31:40 +1100	[thread overview]
Message-ID: <20100125223140.GN25842@discord.disaster> (raw)
In-Reply-To: <20100125115308.GC8595@infradead.org>

On Mon, Jan 25, 2010 at 06:53:08AM -0500, Christoph Hellwig wrote:
> > diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c
> > index 98b8937..ca0cc59 100644
> > --- a/fs/xfs/linux-2.6/xfs_sync.c
> > +++ b/fs/xfs/linux-2.6/xfs_sync.c
> > @@ -270,8 +270,7 @@ xfs_sync_inode_attr(
> >  		goto out_unlock;
> >  	}
> >  
> > -	error = xfs_iflush(ip, (flags & SYNC_WAIT) ?
> > -			   XFS_IFLUSH_SYNC : XFS_IFLUSH_DELWRI);
> > +	error = xfs_iflush(ip, (flags & SYNC_WAIT));
> 
> No need for the masking here, as xfs_iflush simply ignores SYNC_TRYLOCK.

OK.

> >  	/* Now we have an inode that needs flushing */
> >  	error = xfs_iflush(ip, sync_mode);
> > +	if (!(sync_mode & SYNC_WAIT))
> > +		goto requeue_no_flock;
> 
> So for the !wait case we entirely ignore the return value?  We should
> at least check for an I/O error here I think.

I'm not sure we can get an error on a delayed write that we
need to take action on. We don't actually issue the IO from this
call, so the only error case is on reading the buffer. If we get
an error there, what should be do?

My thinking was that if we can't write back the inode, we can't
reclaim it, and if the error is from a transient read error (e.g. FC
path failover) we should be retrying anyway as we do in
xfs_buf_iodone_callbacks()...

> Also in this context
> the requeue label name doesn't fit too well, even if it's the same
> action as the requeue.

I'm open to suggestions for a better name ;)

Cheers,

Dave
-- 
Dave Chinner
david@fromorbit.com

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

  reply	other threads:[~2010-01-25 22:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-25  6:22 [PATCH 0/7] Delayed write metadata writeback V3 Dave Chinner
2010-01-25  6:22 ` [PATCH 1/7] xfs: Make inode reclaim states explicit Dave Chinner
2010-01-25 11:47   ` Christoph Hellwig
2010-01-25  6:22 ` [PATCH 2/7] xfs: Use delayed write for inodes rather than async Dave Chinner
2010-01-25 11:53   ` Christoph Hellwig
2010-01-25 22:31     ` Dave Chinner [this message]
2010-01-26  7:28       ` Dave Chinner
2010-01-26 16:10       ` Christoph Hellwig
2010-02-01 22:59         ` Dave Chinner
2010-01-25 15:29   ` Christoph Hellwig
2010-01-25  6:22 ` [PATCH 3/7] xfs: Don't issue buffer IO direct from AIL push Dave Chinner
2010-01-25 11:59   ` Christoph Hellwig
2010-01-25  6:22 ` [PATCH 4/7] xfs: Sort delayed write buffers before dispatch Dave Chinner
2010-01-25 12:00   ` Christoph Hellwig
2010-01-26  4:13     ` Dave Chinner
2010-01-25  6:22 ` [PATCH 5/7] xfs: Use delay write promotion for dquot flushing Dave Chinner
2010-01-25 12:03   ` Christoph Hellwig
2010-01-25  6:22 ` [PATCH 6/7] xfs: kill the unused XFS_QMOPT_* flush flags Dave Chinner
2010-01-25 12:04   ` Christoph Hellwig
2010-01-25  6:22 ` [PATCH 7/7] xfs: xfs_fs_write_inode() can fail to write inodes synchronously Dave Chinner
2010-01-25 16:03   ` Christoph Hellwig
2010-01-26  4:51     ` Dave Chinner

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=20100125223140.GN25842@discord.disaster \
    --to=david@fromorbit.com \
    --cc=hch@infradead.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