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

Christoph Hellwig hch at infradead.org
Wed Feb 17 13:29:38 CST 2010


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.

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

Reviewed-by: Christoph Hellwig <hch at lst.de>




More information about the xfs mailing list