xfs
[Top] [All Lists]

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

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfs: Non-blocking inode locking in IO completion
From: Alex Elder <aelder@xxxxxxx>
Date: Thu, 25 Feb 2010 14:06:46 -0600
Cc: xfs@xxxxxxxxxxx
In-reply-to: <1266384989-28928-1-git-send-email-david@xxxxxxxxxxxxx>
References: <1266384989-28928-1-git-send-email-david@xxxxxxxxxxxxx>
Reply-to: aelder@xxxxxxx
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);
>  }
>  
>  /*



<Prev in Thread] Current Thread [Next in Thread>