[Top] [All Lists]

Re: [PATCH] xfs: check for stale inode before acquiring iflock on push

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: [PATCH] xfs: check for stale inode before acquiring iflock on push
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Mon, 18 Jun 2012 09:29:35 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <1339425583-54949-1-git-send-email-bfoster@xxxxxxxxxx>
References: <1339425583-54949-1-git-send-email-bfoster@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 06/11/12 09:39, Brian Foster wrote:
An inode in the AIL can be flush locked and marked stale if
a cluster free transaction occurs at the right time. The
inode item is then marked as flushing, which causes xfsaild
to spin and leaves the filesystem stalled. This is
reproduced by running xfstests 273 in a loop for an
extended period of time.

Check for stale inodes before the flush lock. This marks
the inode as pinned, leads to a log flush and allows the
filesystem to proceed.

Signed-off-by: Brian Foster<bfoster@xxxxxxxxxx>

This patch resolves the stall I was reproducing with the 273 loop test.
I repeated the test pretty much throughout the weekend. I still hit one
hung task timeout message, but the test proceeded through it.

Dave, I know you mentioned you were sending a similar patch. Either you
didn't get to it or I missed it, but here's what I've been testing....


  fs/xfs/xfs_inode_item.c |   17 ++++++++---------
  1 files changed, 8 insertions(+), 9 deletions(-)

Your patch looks good. Considered it also:

Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>

As far as problem 2. Small logs can still get stuck. I have seen
hang B in 576K-1MB sized logs, I have not larger logs hard enough
to see where the problem will start to occur.

A) Test like the problem replicator
   will quickly hang because the test can get into a situation where
   there are no new transactions to push the AIL and the sync
   worker's allocation of the dummy transaction is hung behind these

   This is mostly a limit of the test. Any filesystem activity that is
   not related to the test will restart the filesystem. My earlier
   posted patch that restarts the AIL cleaning when there are still
   waiters after the last tail move will help this situation.

B) Keep pushing the log long enough and there will be a hard hang with
   an empty AIL
 1) Large request for log. (typically about 340K)
  a) some free space but not enough for first request
 2) AIL is empty
 3) Remaining space (not quite half the log) is in CIL
  a) current CTX is too small for passive CIL push (just less than log
     size / 8)
  b) remaining space is in the current CTX ticket and a previously
     pushed CTX sequence.
    i) No leaks.
    ii) I have not worked out why the previously pushed CTX has not
       been written out. The iclog looks unlocked and ACTIVE.
 4) The sync worker is blocked on the dummy transaction allocation and
    cannot not push the CIL again.

Sorry this machine will not kdump.

--Mark Tinguely

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