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
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.