1. 10 11月, 2010 2 次提交
  2. 09 11月, 2010 2 次提交
    • S
      ceph: fix update of ctime from MDS · d8672d64
      Sage Weil 提交于
      The client can have a newer ctime than the MDS due to AUTH_EXCL and
      XATTR_EXCL caps as well; update the check in ceph_fill_file_time
      appropriately.
      
      This fixes cases where ctime/mtime goes backward under the right sequence
      of local updates (e.g. chmod) and mds replies (e.g. subsequent stat that
      goes to the MDS).
      Signed-off-by: NSage Weil <sage@newdream.net>
      d8672d64
    • S
      ceph: fix version check on racing inode updates · 8bd59e01
      Sage Weil 提交于
      We may get updates on the same inode from multiple MDSs; generally we only
      pay attention if the update is newer than what we already have.  The
      exception is when an MDS sense unstable information, in which case we
      always update.
      
      The old > check got this wrong when our version was odd (e.g. 3) and the
      reply version was even (e.g. 2): the older stale (v2) info would be
      applied.  Fixed and clarified the comment.
      Signed-off-by: NSage Weil <sage@newdream.net>
      8bd59e01
  3. 08 11月, 2010 6 次提交
    • S
      ceph: fix uid/gid on resent mds requests · cb4276cc
      Sage Weil 提交于
      MDS requests can be rebuilt and resent in non-process context, but were
      filling in uid/gid from current_fsuid/gid.  Put that information in the
      request struct on request setup.
      
      This fixes incorrect (and root) uid/gid getting set for requests that
      are forwarded between MDSs, usually due to metadata migrations.
      Signed-off-by: NSage Weil <sage@newdream.net>
      cb4276cc
    • S
      ceph: fix rdcache_gen usage and invalidate · cd045cb4
      Sage Weil 提交于
      We used to use rdcache_gen to indicate whether we "might" have cached
      pages.  Now we just look at the mapping to determine that.  However, some
      old behavior remains from that transition.
      
      First, rdcache_gen == 0 no longer means we have no pages.  That can happen
      at any time (presumably when we carry FILE_CACHE).  We should not reset it
      to zero, and we should not check that it is zero.
      
      That means that the only purpose for rdcache_revoking is to resolve races
      between new issues of FILE_CACHE and an async invalidate.  If they are
      equal, we should invalidate.  On success, we decrement rdcache_revoking,
      so that it is no longer equal to rdcache_gen.  Similarly, if we success
      in doing a sync invalidate, set revoking = gen - 1.  (This is a small
      optimization to avoid doing unnecessary invalidate work and does not
      affect correctness.)
      Signed-off-by: NSage Weil <sage@newdream.net>
      cd045cb4
    • 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
  4. 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
  5. 21 10月, 2010 14 次提交
  6. 07 10月, 2010 6 次提交
  7. 18 9月, 2010 2 次提交
  8. 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
  9. 15 9月, 2010 2 次提交
  10. 14 9月, 2010 1 次提交
  11. 12 9月, 2010 2 次提交