Skip to content
  1. Aug 23, 2010
    • Sage Weil's avatar
      ceph: queue cap snap writeback for realm children on snap update · ed326044
      Sage Weil authored
      
      
      When a realm is updated, we need to queue writeback on inodes in that
      realm _and_ its children.  Otherwise, if the inode gets cowed on the
      server, we can get a hang later due to out-of-sync cap/snap state.
      
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      ed326044
    • 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. Aug 11, 2010
  3. Aug 06, 2010
    • 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. Aug 04, 2010
  5. Aug 03, 2010
  6. Aug 02, 2010