1. 08 11月, 2010 4 次提交
    • S
      ceph: re-request max_size if cap auth changes · feb4cc9b
      Sage Weil 提交于
      If the auth cap migrates to another MDS, clear requested_max_size so that
      we resend any pending max_size increase requests.  This fixes potential
      hangs on writes that extend a file and race with an cap migration between
      MDSs.
      Signed-off-by: NSage Weil <sage@newdream.net>
      feb4cc9b
    • S
      ceph: only let auth caps update max_size · 912a9b03
      Sage Weil 提交于
      Only the auth MDS has a meaningful max_size value for us, so only update it
      in fill_inode if we're being issued an auth cap.  Otherwise, a random
      stat result from a non-auth MDS can clobber a meaningful max_size, get
      the client<->mds cap state out of sync, and make writes hang.
      
      Specifically, even if the client re-requests a larger max_size (which it
      will), the MDS won't respond because as far as it knows we already have a
      sufficiently large value.
      Signed-off-by: NSage Weil <sage@newdream.net>
      912a9b03
    • S
      ceph: fix open for write on clustered mds · 7421ab80
      Sage Weil 提交于
      Normally when we open a file we already have a cap, and simply update the
      wanted set.  However, if we open a file for write, but don't have an auth
      cap, that doesn't work; we need to open a new cap with the auth MDS.  Only
      reuse existing caps if we are opening for read or the existing cap is auth.
      Signed-off-by: NSage Weil <sage@newdream.net>
      7421ab80
    • S
      ceph: fix bad pointer dereference in ceph_fill_trace · d8b16b3d
      Sage Weil 提交于
      We dereference *in a few lines down, but only set it on rename.  It is
      apparently pretty rare for this to trigger, but I have been hitting it
      with a clustered MDSs.
      Signed-off-by: NSage Weil <sage@newdream.net>
      d8b16b3d
  2. 28 10月, 2010 1 次提交
    • S
      Revert "ceph: update issue_seq on cap grant" · 2f56f56a
      Sage Weil 提交于
      This reverts commit d91f2438.
      
      The intent of issue_seq is to distinguish between mds->client messages that
      (re)create the cap and those that do not, which means we should _only_ be
      updating that value in the create paths.  By updating it in handle_cap_grant,
      we reset it to zero, which then breaks release.
      
      The larger question is what workload/problem made me think it should be
      updated here...
      Signed-off-by: NSage Weil <sage@newdream.net>
      2f56f56a
  3. 21 10月, 2010 14 次提交
  4. 07 10月, 2010 6 次提交
  5. 18 9月, 2010 2 次提交
  6. 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
  7. 15 9月, 2010 2 次提交
  8. 14 9月, 2010 1 次提交
  9. 12 9月, 2010 4 次提交
  10. 27 8月, 2010 3 次提交
  11. 26 8月, 2010 1 次提交
    • A
      ceph: Fix warnings · ad8453ab
      Alan Cox 提交于
      Just scrubbing some warnings so I can see real problem ones in the build
      noise. For 32bit we need to coax gcc politely into believing we really
      honestly intend to the casts. Using (u64)(unsigned long) means we cast from
      a pointer to a type of the right size and then extend it. This stops the
      warning spew.
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NSage Weil <sage@newdream.net>
      ad8453ab