Re: [PATCH] xfs: Non-blocking inode locking in IO completion

[Alex Elder <aelder@sgi.com>]

On Wed, 2010-02-17 at 16:36 +1100, Dave Chinner wrote:
> The introduction of barriers to DM loop devices (e.g. dm-crypt) has
> created a new IO order completion dependency that XFS does not
> handle. That is, the completion of log IOs (which have barriers) in
> the loop filesystem are now dependent on completion of data IO in
> the backing filesystem.

One comment, below

. . .

> +	if (ioend->io_type != IOMAP_READ) {
> +		error = xfs_setfilesize(ioend);
> +		ASSERT(!error || error == EAGAIN);
>  	}
> +
> +	/*
> +	 * If we didn't complete processing of the ioend, requeue it to the
> +	 * tail of the workqueue for another attempt later. Otherwise destroy
> +	 * it.
> +	 */
> +	if (error == EAGAIN) {

It's not a problem now (and may never be), but it's
conceivable error could have been set to the return
value from xfs_iomap_write_unwritten() to have value
EAGAIN.  It might have been better to include this
block inside the if (ioend->io_type != IOMAP_READ) {
block, above.

(I'll take it as is, however...)

					-Alex




> +		atomic_inc(&ioend->io_remaining);
> +		xfs_finish_ioend(ioend, 0);
> +		/* ensure we don't spin on blocked ioends */
> +		delay(1);
> +	} else
> +		xfs_destroy_ioend(ioend);
>  }
>  
>  /*



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