Re: [PATCH 2/7] xfs: split inode flushing from xfs_sync_inodes_ag

[Eric Sandeen <sandeen@sandeen.net>]

Christoph Hellwig wrote:
> In many cases we only want to sync inode metadata. Split out the inode
> flushing into a separate helper to prepare factoring the inode sync code.
> 
> Based on a patch from Dave Chinner, but redone to keep the current behaviour
> exactly and leave changes to the flushing logic to another patch.
> 
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> Index: xfs/fs/xfs/linux-2.6/xfs_sync.c
> ===================================================================
> --- xfs.orig/fs/xfs/linux-2.6/xfs_sync.c	2009-05-14 16:17:41.359813297 +0200
> +++ xfs/fs/xfs/linux-2.6/xfs_sync.c	2009-05-14 19:05:25.545684101 +0200
> @@ -76,6 +76,34 @@ xfs_sync_inode_data(
>  	return error;
>  }
>  
> +STATIC int
> +xfs_sync_inode_attr(
> +	struct xfs_inode	*ip,
> +	int			flags)
> +{
> +	int			error = 0;
> +
> +	xfs_ilock(ip, XFS_ILOCK_SHARED);
> +	if (xfs_inode_clean(ip))
> +		goto out_unlock;
> +	if (!xfs_iflock_nowait(ip)) {
> +		if (!(flags & SYNC_WAIT))
> +			goto out_unlock;
> +		xfs_iflock(ip);
> +	}
> +
> +	if (xfs_inode_clean(ip)) {
> +		xfs_ifunlock(ip);
> +		goto out_unlock;
> +	}
> +
> +	error = xfs_iflush(ip, XFS_IFLUSH_SYNC);
> +
> + out_unlock:
> +	xfs_iunlock(ip, XFS_ILOCK_SHARED);
> +	return error;
> +}
> +
>  /*
>   * Sync all the inodes in the given AG according to the
>   * direction given by the flags.

...

> @@ -154,22 +181,10 @@ xfs_sync_inodes_ag(
>  		if (flags & SYNC_DELWRI)
>  			error = xfs_sync_inode_data(ip, flags);
>  
> -		xfs_ilock(ip, XFS_ILOCK_SHARED);
> -		if ((flags & SYNC_ATTR) && !xfs_inode_clean(ip)) {
> -			if (flags & SYNC_WAIT) {
> -				xfs_iflock(ip);
> -				if (!xfs_inode_clean(ip))
> -					error = xfs_iflush(ip, XFS_IFLUSH_SYNC);
> -				else
> -					xfs_ifunlock(ip);
> -			} else if (xfs_iflock_nowait(ip)) {
> -				if (!xfs_inode_clean(ip))
> -					error = xfs_iflush(ip, XFS_IFLUSH_DELWRI);

What happened to the XFS_IFLUSH_DELWRI case?

You mentioned "keep the current behavior exactly" but this seems like a
change, no?

-Eric

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