1. 21 10月, 2010 3 次提交
  2. 07 10月, 2010 6 次提交
  3. 18 9月, 2010 2 次提交
  4. 17 9月, 2010 2 次提交
    • S
      ceph: only send one flushsnap per cap_snap per mds session · e835124c
      Sage Weil 提交于
      Sending multiple flushsnap messages is problematic because we ignore
      the response if the tid doesn't match, and the server may only respond to
      each one once.  It's also a waste.
      
      So, skip cap_snaps that are already on the flushing list, unless the caller
      tells us to resend (because we are reconnecting).
      Signed-off-by: NSage Weil <sage@newdream.net>
      e835124c
    • S
      ceph: fix cap_snap and realm split · ae00d4f3
      Sage Weil 提交于
      The cap_snap creation/queueing relies on both the current i_head_snapc
      _and_ the i_snap_realm pointers being correct, so that the new cap_snap
      can properly reference the old context and the new i_head_snapc can be
      updated to reference the new snaprealm's context.  To fix this, we:
      
       - move inodes completely to the new (split) realm so that i_snap_realm
         is correct, and
       - generate the new snapc's _before_ queueing the cap_snaps in
         ceph_update_snap_trace().
      Signed-off-by: NSage Weil <sage@newdream.net>
      ae00d4f3
  5. 15 9月, 2010 2 次提交
  6. 14 9月, 2010 1 次提交
  7. 12 9月, 2010 4 次提交
  8. 27 8月, 2010 3 次提交
  9. 26 8月, 2010 2 次提交
  10. 25 8月, 2010 2 次提交
  11. 23 8月, 2010 8 次提交
  12. 11 8月, 2010 1 次提交
  13. 06 8月, 2010 1 次提交
    • S
      ceph: only queue async writeback on cap revocation if there is dirty data · 0eb6cd49
      Sage Weil 提交于
      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: NSage Weil <sage@newdream.net>
      0eb6cd49
  14. 04 8月, 2010 3 次提交