xfs
[Top] [All Lists]

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

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfs: Non-blocking inode locking in IO completion
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 18 Feb 2010 08:13:12 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20100217192938.GA14015@xxxxxxxxxxxxx>
References: <1266384989-28928-1-git-send-email-david@xxxxxxxxxxxxx> <20100217192938.GA14015@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
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@xxxxxxxxxxxxx

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