1. 22 Aug, 2010 3 commits
    • Sage Weil's avatar
      ceph: include dirty xattrs state in snapped caps · 4a625be4
      Sage Weil authored
      When we snapshot dirty metadata that needs to be written back to the MDS,
      include dirty xattr metadata.  Make the capsnap reference the encoded
      xattr blob so that it will be written back in the FLUSHSNAP op.
      
      Also fix the capsnap creation guard to include dirty auth or file bits,
      not just tests specific to dirty file data or file writes in progress
      (this fixes auth metadata writeback).
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      4a625be4
    • Sage Weil's avatar
      ceph: fix xattr cap writeback · 082afec9
      Sage Weil authored
      We should include the xattr metadata blob in the cap update message any
      time we are flushing dirty state, NOT just when we are also dropping the
      cap.  This fixes async xattr writeback.
      
      Also, clean up the code slightly to avoid duplicating the bit test.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      082afec9
    • Sage Weil's avatar
      ceph: fix multiple mds session shutdown · f3c60c59
      Sage Weil authored
      The use of a completion when waiting for session shutdown during umount is
      inappropriate, given the complexity of the condition.  For multiple MDS's,
      this resulted in the umount thread spinning, often preventing the session
      close message from being processed in some cases.
      
      Switch to a waitqueue and defined a condition helper.  This cleans things
      up nicely.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      f3c60c59
  2. 10 Aug, 2010 1 commit
  3. 05 Aug, 2010 1 commit
    • Sage Weil's avatar
      ceph: only queue async writeback on cap revocation if there is dirty data · 0eb6cd49
      Sage Weil authored
      Normally, if the Fb cap bit is being revoked, we queue an async writeback.
      If there is no dirty data but we still hold the cap, this leaves the
      client sitting around doing nothing until the cap timeouts expire and the
      cap is released on its own (as it would have been without the revocation).
      
      Instead, only queue writeback if the bit is actually used (i.e., we have
      dirty data).  If not, we can reply to the revocation immediately.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      0eb6cd49
  4. 03 Aug, 2010 3 commits
  5. 02 Aug, 2010 32 commits