1. 21 2月, 2011 1 次提交
    • T
      ocfs2: Remove ENTRY from masklog. · ef6b689b
      Tao Ma 提交于
      ENTRY is used to record the entry of a function.
      But because it is added in so many functions, if we enable it,
      the system logs get filled up quickly and cause too much I/O.
      So actually no one can open it for a production system or even
      for a test.
      
      So for mlog_entry_void, we just remove it.
      for mlog_entry(...), we replace it with mlog(0,...), and they
      will be replace by trace event later.
      Signed-off-by: NTao Ma <boyu.mt@taobao.com>
      ef6b689b
  2. 08 8月, 2010 1 次提交
    • W
      ocfs2/dlm: avoid incorrect bit set in refmap on recovery master · a524812b
      Wengang Wang 提交于
      In the following situation, there remains an incorrect bit in refmap on the
      recovery master. Finally the recovery master will fail at purging the lockres
      due to the incorrect bit in refmap.
      
      1) node A has no interest on lockres A any longer, so it is purging it.
      2) the owner of lockres A is node B, so node A is sending de-ref message
      to node B.
      3) at this time, node B crashed. node C becomes the recovery master. it recovers
      lockres A(because the master is the dead node B).
      4) node A migrated lockres A to node C with a refbit there.
      5) node A failed to send de-ref message to node B because it crashed. The failure
      is ignored. no other action is done for lockres A any more.
      
      For mormal, re-send the deref message to it to recovery master can fix it. Well,
      ignoring the failure of deref to the original master and not recovering the lockres
      to recovery master has the same effect. And the later is simpler.
      Signed-off-by: NWengang Wang <wen.gang.wang@oracle.com>
      Acked-by: NSrinivas Eeda <srinivas.eeda@oracle.com>
      Cc: stable@kernel.org
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      a524812b
  3. 13 7月, 2010 1 次提交
  4. 06 5月, 2010 1 次提交
  5. 27 2月, 2010 1 次提交
  6. 04 2月, 2010 1 次提交
  7. 03 2月, 2010 1 次提交
  8. 26 1月, 2010 3 次提交
  9. 03 12月, 2009 1 次提交
  10. 24 9月, 2009 1 次提交
  11. 09 7月, 2009 1 次提交
  12. 11 3月, 2008 4 次提交
  13. 26 1月, 2008 2 次提交
    • T
      ocfs2/dlm: Clear joining_node on hearbeat node down · 2d4b1cbb
      Tao Ma 提交于
      Currently the process of dlm join contains 2 steps: query join and assert join.
      After query join, the joined node will set its joining_node. So if the joining
      node happens to panic before the 2nd step, the joined node will fail to clear
      its joining_node flag because that node isn't in the domain map. It at least
      cause 2 problems.
      1. All the new join request will fail. So no new node can mount the volume.
      2. The joined node can't umount the volume since during the umount process it
         has to wait for the joining_node to be unknown. So the umount will be hanged.
      
      The solution is to clear the joining_node before we check the domain map.
      Signed-off-by: NTao Ma <tao.ma@oracle.com>
      Signed-off-by: NMark Fasheh <mark.fasheh@oracle.com>
      2d4b1cbb
    • M
      ocfs2_dlm: Call node eviction callbacks from heartbeat handler · 6561168c
      Mark Fasheh 提交于
      With this, a dlm client can take advantage of the group protocol in the dlm
      to get full notification whenever a node within the dlm domain leaves
      unexpectedly.
      Signed-off-by: NMark Fasheh <mark.fasheh@oracle.com>
      6561168c
  14. 20 10月, 2007 1 次提交
  15. 11 7月, 2007 2 次提交
  16. 03 5月, 2007 1 次提交
  17. 27 4月, 2007 1 次提交
  18. 08 2月, 2007 8 次提交
  19. 14 12月, 2006 1 次提交
  20. 22 11月, 2006 1 次提交
  21. 25 9月, 2006 1 次提交
  22. 30 6月, 2006 1 次提交
  23. 28 6月, 2006 1 次提交
  24. 27 6月, 2006 3 次提交