[PATCH] xfs: Non-blocking inode locking in IO completion
Alex Elder
aelder at sgi.com
Thu Feb 25 14:06:46 CST 2010
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);
> }
>
> /*
More information about the xfs
mailing list