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