1. 28 Sep, 2011 2 commits
    • Sage Weil's avatar
      libceph: fix pg_temp mapping update · 8adc8b3d
      Sage Weil authored
      The incremental map updates have a record for each pg_temp mapping that is
      to be add/updated (len > 0) or removed (len == 0).  The old code was
      written as if the updates were a complete enumeration; that was just wrong.
      Update the code to remove 0-length entries and drop the rbtree traversal.
      
      This avoids misdirected (and hung) requests that manifest as server
      errors like
      
      [WRN] client4104 10.0.1.219:0/275025290 misdirected client4104.1:129 0.1 to osd0 not [1,0] in e11/11
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      8adc8b3d
    • Sage Weil's avatar
      libceph: fix pg_temp mapping calculation · 782e182e
      Sage Weil authored
      We need to apply the modulo pg_num calculation before looking up a pgid in
      the pg_temp mapping rbtree.  This fixes pg_temp mappings, and fixes
      (some) misdirected requests that result in messages like
      
      [WRN] client4104 10.0.1.219:0/275025290 misdirected client4104.1:129 0.1 to osd0 not [1,0] in e11/11
      
      on the server and stall make the client block without getting a reply (at
      least until the pg_temp mapping goes way, but that can take a long long
      time).
      
      Reorder calc_pg_raw() a bit to make more sense.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      782e182e
  2. 16 Sep, 2011 3 commits
  3. 31 Aug, 2011 1 commit
  4. 22 Aug, 2011 1 commit
  5. 15 Aug, 2011 1 commit
  6. 09 Aug, 2011 1 commit
    • Sage Weil's avatar
      libceph: fix msgpool · 5185352c
      Sage Weil authored
      There were several problems here:
      
       1- we weren't tagging allocations with the pool, so they were never
          returned to the pool.
       2- msgpool_put didn't add back to the mempool, even it were called.
       3- msgpool_release didn't clear the pool pointer, so it would have looped
          had #1 not been broken.
      
      These may or may not have been responsible for #1136 or #1381 (BUG due to
      non-empty mempool on umount).  I can't seem to trigger the crash now using
      the method I was using before.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      5185352c
  7. 26 Jul, 2011 23 commits
  8. 22 Jul, 2011 2 commits
  9. 21 Jul, 2011 6 commits