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

[Dave Chinner]

On Wed, Feb 17, 2010 at 02:29:38PM -0500, Christoph Hellwig wrote:
> On Wed, Feb 17, 2010 at 04:36:29PM +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.
> 
> I don't think dm belongs into the picture here at all.  The problem
> is simply with the loop device, which sits below dm-crypt in the
> bugzilla reports.  The loop device in SuSE (and for a short time in
> mainline until we saw unexplainable XFS lockups) implements barriers
> using fsync.  Now that fsync turns a log I/O that issues a barrier
> in the XFS filesystem inside the loop device into a data I/O the
> backing filesystem.  With this the rest of your description applies
> again.

Fair point. I'll change the description to be more accurate.

> The patch looks good to me - while I hate introducing random delay()
> calls I don't really see a way around this. 

I thought about using queue_delayed_work(), but then the change
became much bigger and has other side effects like increasing the
size of the ioend structure.

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com