mds: don't wait for lock 'flushing' flag on replicas

If we are a replica, the 'flushing' means that we had dirty scatterlock
data and are waiting for it to get flushed out to the auth copy (by
cycling from MIX->LOCK, normally).  If we end up with 'flushing' set
while in the MIX state, we can't wait for it to clear before responding
to a lock request from the primary or we'll deadlock.

On the auth, flushing means flushing to the log, which makes sense; that
will always make progress despite scatterlock activity.

This fixes a hang from 3-mds fsstress with thrashing exports.  (Strangely
I never hit this on fatty.)

Signed-off-by: Sage Weil <sage@newdream.net>

diff --git a/src/mds/Locker.cc b/src/mds/Locker.cc
index c4ca7d8735daee85f082f9d7d5621a33c74f8286..acf82c352e3b0a5e8dd55262b13cbc648b91aeec 100644 (file)
--- a/src/mds/Locker.cc
+++ b/src/mds/Locker.cc
@@ -569,7 +569,7 @@ void Locker::eval_gather(SimpleLock *lock, bool first, bool *pneed_issue, list<C
       (IS_TRUE_AND_LT_AUTH(lock->get_sm()->states[next].can_wrlock, auth) || !lock->is_wrlocked()) &&
       (IS_TRUE_AND_LT_AUTH(lock->get_sm()->states[next].can_xlock, auth) || !lock->is_xlocked()) &&
       (IS_TRUE_AND_LT_AUTH(lock->get_sm()->states[next].can_lease, auth) || !lock->is_leased()) &&
-      (!lock->is_flushing()) &&  // i.e. wait for scatter_writebehind!
+      !(lock->get_parent()->is_auth() && lock->is_flushing()) &&  // i.e. wait for scatter_writebehind!
       (!caps || ((~lock->gcaps_allowed(CAP_ANY, next) & other_issued) == 0 &&
                 (~lock->gcaps_allowed(CAP_LONER, next) & loner_issued) == 0 &&
                 (~lock->gcaps_allowed(CAP_XLOCKER, next) & xlocker_issued) == 0)) &&