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: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed, 17 Feb 2010 14:29:38 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <1266384989-28928-1-git-send-email-david@xxxxxxxxxxxxx>
References: <1266384989-28928-1-git-send-email-david@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.19 (2009-01-05)
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@xxxxxx>

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