xfs
[Top] [All Lists]

Re: Hung in D state during fclose

To: "Cheung, Norman" <Norman.Cheung@xxxxxxxxxxxxxx>
Subject: Re: Hung in D state during fclose
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 27 Feb 2013 07:31:35 +1100
Cc: "'linux-xfs@xxxxxxxxxxx'" <linux-xfs@xxxxxxxxxxx>
Delivered-to: linux-xfs@xxxxxxxxxxx
In-reply-to: <3542214BE3A3EF419F236DFE0F878BC9055A4A@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <20130212065545.GC10731@dastard> <3542214BE3A3EF419F236DFE0F878BC90512DC@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20130212102014.GA26694@dastard> <3542214BE3A3EF419F236DFE0F878BC90517D2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20130212202246.GB26694@dastard> <3542214BE3A3EF419F236DFE0F878BC905190D@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <3542214BE3A3EF419F236DFE0F878BC9051A09@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20130213051552.GF26694@dastard> <3542214BE3A3EF419F236DFE0F878BC9052F35@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <3542214BE3A3EF419F236DFE0F878BC9055A4A@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Feb 26, 2013 at 07:41:42PM +0000, Cheung, Norman wrote:
> I'd been checking all the XFS patches if any might relate to my situation and 
> came across this 
> http://article.gmane.org/gmane.comp.file-systems.xfs.general/40349/
> 
> From: Christoph Hellwig <hch <at> infradead.org>
> Subject: [PATCH, RFC] writeback: avoid redirtying when ->write_inode failed 
> to clear I_DIRTY
> Newsgroups: gmane.comp.file-systems.xfs.general
> Date: 2011-08-27 06:14:09 GMT (1 year, 26 weeks, 1 day, 13 hours and 17 
> minutes ago)
> Right now ->write_inode has no way to safely return a EAGAIN without 
> explicitly
> redirtying the inode, as we would lose the dirty state otherwise.  Most
> filesystems get this wrong, but XFS makes heavy use of it to avoid blocking
> the flusher thread when ->write_inode hits contentended inode locks.  A
> contended ilock is something XFS can hit very easibly when extending files, as
> the data I/O completion handler takes the lock to update the size, and the
> ->write_inode call can race with it fairly easily if writing enough data
> in one go so that the completion for the first write come in just before
> we call ->write_inode.
> 
> Change the handling of this case to use requeue_io for a quick retry instead
> of redirty_tail, which keeps moving out the dirtied_when data and thus keeps
> delaying the writeout more and more with every failed attempt to get the lock.
> 
> I wonder if this would have caused my application waiting for xfs_ilock.  I 
> checked 
> that  this patch is not in my kernel source (SUSE 11 SP2, Rel 3.0.13-0.27)

I have no idea whether it will help or not, because SuSE (like Red
Hat) ship a heavily patched kernel and so it's rather hard for
anyone here to triage and diagnose problems like this. Further, even
if we can find a potential cause, we still can't fix it for you.
Hence perhaps you are best advised to talk to your SuSE support
contact at this point?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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