1. 20 5月, 2011 1 次提交
  2. 04 5月, 2011 1 次提交
  3. 07 4月, 2011 1 次提交
  4. 31 3月, 2011 1 次提交
  5. 30 3月, 2011 1 次提交
    • S
      libceph: fix null dereference when unregistering linger requests · fbdb9190
      Sage Weil 提交于
      We should only clear r_osd if we are neither registered as a linger or a
      regular request.  We may unregister as a linger while still registered as
      a regular request (e.g., in reset_osd).  Incorrectly clearing r_osd there
      leads to a null pointer dereference in __send_request.
      
      Also simplify the parallel check in __unregister_request() where we just
      removed r_osd_item and know it's empty.
      Signed-off-by: NSage Weil <sage@newdream.net>
      fbdb9190
  6. 29 3月, 2011 1 次提交
  7. 27 3月, 2011 1 次提交
  8. 23 3月, 2011 1 次提交
  9. 22 3月, 2011 1 次提交
    • S
      libceph: fix osd request queuing on osdmap updates · 6f6c7006
      Sage Weil 提交于
      If we send a request to osd A, and the request's pg remaps to osd B and
      then back to A in quick succession, we need to resend the request to A. The
      old code was only calling kick_requests after processing all incremental
      maps in a message, so it was very possible to not resend a request that
      needed to be resent.  This would make the osd eventually time out (at least
      with the current default of osd timeouts enabled).
      
      The correct approach is to scan requests on every map incremental.  This
      patch refactors the kick code in a few ways:
       - all requests are either on req_lru (in flight), req_unsent (ready to
         send), or req_notarget (currently map to no up osd)
       - mapping always done by map_request (previous map_osds)
       - if the mapping changes, we requeue.  requests are resent only after all
         map incrementals are processed.
       - some osd reset code is moved out of kick_requests into a separate
         function
       - the "kick this osd" functionality is moved to kick_osd_requests, as it
         is unrelated to scanning for request->pg->osd mapping changes
      Signed-off-by: NSage Weil <sage@newdream.net>
      6f6c7006
  10. 10 11月, 2010 2 次提交
    • S
      ceph: explicitly specify page alignment in network messages · c5c6b19d
      Sage Weil 提交于
      The alignment used for reading data into or out of pages used to be taken
      from the data_off field in the message header.  This only worked as long
      as the page alignment matched the object offset, breaking direct io to
      non-page aligned offsets.
      
      Instead, explicitly specify the page alignment next to the page vector
      in the ceph_msg struct, and use that instead of the message header (which
      probably shouldn't be trusted).  The alloc_msg callback is responsible for
      filling in this field properly when it sets up the page vector.
      Signed-off-by: NSage Weil <sage@newdream.net>
      c5c6b19d
    • S
      ceph: make page alignment explicit in osd interface · b7495fc2
      Sage Weil 提交于
      We used to infer alignment of IOs within a page based on the file offset,
      which assumed they matched.  This broke with direct IO that was not aligned
      to pages (e.g., 512-byte aligned IO).  We were also trusting the alignment
      specified in the OSD reply, which could have been adjusted by the server.
      
      Explicitly specify the page alignment when setting up OSD IO requests.
      Signed-off-by: NSage Weil <sage@newdream.net>
      b7495fc2
  11. 21 10月, 2010 4 次提交
  12. 07 10月, 2010 1 次提交
  13. 23 8月, 2010 1 次提交
  14. 04 8月, 2010 1 次提交
  15. 02 8月, 2010 1 次提交
  16. 28 7月, 2010 1 次提交
  17. 14 6月, 2010 1 次提交
  18. 30 5月, 2010 1 次提交
  19. 22 5月, 2010 1 次提交
  20. 18 5月, 2010 8 次提交
  21. 12 5月, 2010 2 次提交
  22. 23 3月, 2010 3 次提交
    • S
      ceph: avoid reopening osd connections when address hasn't changed · 87b315a5
      Sage Weil 提交于
      We get a fault callback on _every_ tcp connection fault.  Normally, we
      want to reopen the connection when that happens.  If the address we have
      is bad, however, and connection attempts always result in a connection
      refused or similar error, explicitly closing and reopening the msgr
      connection just prevents the messenger's backoff logic from kicking in.
      The result can be a console full of
      
      [ 3974.417106] ceph: osd11 10.3.14.138:6800 connection failed
      [ 3974.423295] ceph: osd11 10.3.14.138:6800 connection failed
      [ 3974.429709] ceph: osd11 10.3.14.138:6800 connection failed
      
      Instead, if we get a fault, and have outstanding requests, but the osd
      address hasn't changed and the connection never successfully connected in
      the first place, do nothing to the osd connection.  The messenger layer
      will back off and retry periodically, because we never connected and thus
      the lossy bit is not set.
      
      Instead, touch each request's r_stamp so that handle_timeout can tell the
      request is still alive and kicking.
      Signed-off-by: NSage Weil <sage@newdream.net>
      87b315a5
    • S
      ceph: rename r_sent_stamp r_stamp · 3dd72fc0
      Sage Weil 提交于
      Make variable name slightly more generic, since it will (soon)
      reflect either the time the request was sent OR the time it was
      last determined to be still retrying.
      Signed-off-by: NSage Weil <sage@newdream.net>
      3dd72fc0
    • S
      ceph: fix null pointer deref of r_osd in debug output · 12eadc19
      Sage Weil 提交于
      This causes an oops when debug output is enabled and we kick
      an osd request with no current r_osd (sometime after an osd
      failure).  Check the pointer before dereferencing.
      Signed-off-by: NSage Weil <sage@newdream.net>
      12eadc19
  23. 05 3月, 2010 1 次提交
    • Y
      ceph: reset osd after relevant messages timed out · 422d2cb8
      Yehuda Sadeh 提交于
      This simplifies the process of timing out messages. We
      keep lru of current messages that are in flight. If a
      timeout has passed, we reset the osd connection, so that
      messages will be retransmitted.  This is a failsafe in case
      we hit some sort of problem sending out message to the OSD.
      Normally, we'll get notification via an updated osdmap if
      there are problems.
      
      If a request is older than the keepalive timeout, send a
      keepalive to ensure we detect any breaks in the TCP connection.
      Signed-off-by: NYehuda Sadeh <yehuda@hq.newdream.net>
      Signed-off-by: NSage Weil <sage@newdream.net>
      422d2cb8
  24. 02 3月, 2010 2 次提交
  25. 27 2月, 2010 1 次提交
    • S
      ceph: remove fragile __map_osds optimization · c99eb1c7
      Sage Weil 提交于
      We used to try to avoid freeing and then reallocating the osd
      struct.  This is a bit fragile due to potential interactions with
      other references (beyond o_requests), and may be the cause of
      this crash:
      
      [120633.442358] BUG: unable to handle kernel NULL pointer dereference at (null)
      [120633.443292] IP: [<ffffffff812549b6>] rb_erase+0x11d/0x277
      [120633.443292] PGD f7ff3067 PUD f7f53067 PMD 0
      [120633.443292] Oops: 0000 [#1] PREEMPT SMP
      [120633.443292] last sysfs file: /sys/kernel/uevent_seqnum
      [120633.443292] CPU 1
      [120633.443292] Modules linked in: ceph fan ac battery psmouse ehci_hcd ide_pci_generic ohci_hcd thermal processor button
      [120633.443292] Pid: 3023, comm: ceph-msgr/1 Not tainted 2.6.32-rc2 #12 H8SSL
      [120633.443292] RIP: 0010:[<ffffffff812549b6>]  [<ffffffff812549b6>] rb_erase+0x11d/0x277
      [120633.443292] RSP: 0018:ffff8800f7b13a50  EFLAGS: 00010246
      [120633.443292] RAX: ffff880022907819 RBX: ffff880022907818 RCX: 0000000000000000
      [120633.443292] RDX: ffff8800f7b13a80 RSI: ffff8800f587eb48 RDI: 0000000000000000
      [120633.443292] RBP: ffff8800f7b13a60 R08: 0000000000000000 R09: 0000000000000004
      [120633.443292] R10: 0000000000000000 R11: ffff8800c4441000 R12: ffff8800f587eb48
      [120633.443292] R13: ffff8800f58eaa00 R14: ffff8800f413c000 R15: 0000000000000001
      [120633.443292] FS:  00007fbef6e226e0(0000) GS:ffff880009200000(0000) knlGS:0000000000000000
      [120633.443292] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      [120633.443292] CR2: 0000000000000000 CR3: 00000000f7c53000 CR4: 00000000000006e0
      [120633.443292] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [120633.443292] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [120633.443292] Process ceph-msgr/1 (pid: 3023, threadinfo ffff8800f7b12000, task ffff8800f5858b40)
      [120633.443292] Stack:
      [120633.443292]  ffff8800f413c000 ffff8800f587e9c0 ffff8800f7b13a80 ffffffffa0098a86
      [120633.443292] <0> 00000000000006f1 0000000000000000 ffff8800f7b13af0 ffffffffa009959b
      [120633.443292] <0> ffff8800f413c000 ffff880022a68400 ffff880022a68400 ffff8800f587e9c0
      [120633.443292] Call Trace:
      [120633.443292]  [<ffffffffa0098a86>] __remove_osd+0x4d/0xbc [ceph]
      [120633.443292]  [<ffffffffa009959b>] __map_osds+0x199/0x4fa [ceph]
      [120633.443292]  [<ffffffffa00999f4>] ? __send_request+0xf8/0x186 [ceph]
      [120633.443292]  [<ffffffffa0099beb>] kick_requests+0x169/0x3cb [ceph]
      [120633.443292]  [<ffffffffa009a8c1>] ceph_osdc_handle_map+0x370/0x522 [ceph]
      
      Since we're probably screwed anyway if a small kmalloc is
      failing, don't bother with trying to be clever here.
      Signed-off-by: NSage Weil <sage@newdream.net>
      c99eb1c7