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.
> > /* 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
> 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 ;)