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
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@xxxxxx>