1. 22 1月, 2014 1 次提交
    • G
      ocfs2: add clustername to cluster connection · c74a3bdd
      Goldwyn Rodrigues 提交于
      This is an effort of removing ocfs2_controld.pcmk and getting ocfs2 DLM
      handling up to the times with respect to DLM (>=4.0.1) and corosync
      (2.3.x).  AFAIK, cman also is being phased out for a unified corosync
      cluster stack.
      
      fs/dlm performs all the functions with respect to fencing and node
      management and provides the API's to do so for ocfs2.  For all future
      references, DLM stands for fs/dlm code.
      
      The advantages are:
       + No need to run an additional userspace daemon (ocfs2_controld)
       + No controld device handling and controld protocol
       + Shifting responsibilities of node management to DLM layer
      
      For backward compatibility, we are keeping the controld handling code.
      Once enough time has passed we can remove a significant portion of the
      code.  This was tested by using the kernel with changes on older
      unmodified tools.  The kernel used ocfs2_controld as expected, and
      displayed the appropriate warning message.
      
      This feature requires modification in the userspace ocfs2-tools.  The
      changes can be found at: https://github.com/goldwynr/ocfs2-tools branch:
      nocontrold Currently, not many checks are present in the userspace code,
      but that would change soon.
      
      This patch (of 6):
      
      Add clustername to cluster connection.
      Signed-off-by: NGoldwyn Rodrigues <rgoldwyn@suse.com>
      Reviewed-by: NMark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c74a3bdd
  2. 31 3月, 2011 1 次提交
  3. 27 2月, 2010 6 次提交
    • J
      ocfs2_dlmfs: Enable the use of user cluster stacks. · cbe0e331
      Joel Becker 提交于
      Unlike ocfs2, dlmfs has no permanent storage.  It can't store off a
      cluster stack it is supposed to be using.  So it can't specify the stack
      name in ocfs2_cluster_connect().
      
      Instead, we create ocfs2_cluster_connect_agnostic(), which simply uses
      the stack that is currently enabled.  This is find for dlmfs, which will
      rely on the stack initialization.
      
      We add the "stackglue" capability to dlmfs's capability list.  This lets
      userspace know dlmfs can be used with all cluster stacks.
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      cbe0e331
    • J
      ocfs2: Pass the locking protocol into ocfs2_cluster_connect(). · 553b5eb9
      Joel Becker 提交于
      Inside the stackglue, the locking protocol structure is hanging off of
      the ocfs2_cluster_connection.  This takes it one further; the locking
      protocol is passed into ocfs2_cluster_connect().  Now different cluster
      connections can have different locking protocols with distinct asts.
      Note that all locking protocols have to keep their maximum protocol
      version in lock-step.
      
      With the protocol structure set in ocfs2_cluster_connect(), there is no
      need for the stackglue to have a static pointer to a specific protocol
      structure.  We can change initialization to only pass in the maximum
      protocol version.
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      553b5eb9
    • J
      ocfs2: Remove the ast pointers from ocfs2_stack_plugins · e603cfb0
      Joel Becker 提交于
      With the full ocfs2_locking_protocol hanging off of the
      ocfs2_cluster_connection, ast wrappers can get the ast/bast pointers
      there.  They don't need to get them from their plugin structure.
      
      The user plugin still needs the maximum locking protocol version,
      though.  This changes the plugin structure so that it only holds the max
      version, not the entire ocfs2_locking_protocol pointer.
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      e603cfb0
    • J
      ocfs2: Hang the locking proto on the cluster conn and use it in asts. · 110946c8
      Joel Becker 提交于
      With the ocfs2_cluster_connection hanging off of the ocfs2_dlm_lksb, we
      have access to it in the ast and bast wrapper functions.  Attach the
      ocfs2_locking_protocol to the conn.
      
      Now, instead of refering to a static variable for ast/bast pointers, the
      wrappers can look at the connection.  This means different connections
      can have different ast/bast pointers, and it reduces the need for the
      static pointer.
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      110946c8
    • J
      ocfs2: Attach the connection to the lksb · c0e41338
      Joel Becker 提交于
      We're going to want it in the ast functions, so we convert union
      ocfs2_dlm_lksb to struct ocfs2_dlm_lksb and let it carry the connection.
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      c0e41338
    • J
      ocfs2: Pass lksbs back from stackglue ast/bast functions. · a796d286
      Joel Becker 提交于
      The stackglue ast and bast functions tried to maintain the fiction that
      their arguments were void pointers.  In reality, stack_user.c had to
      know that the argument was an ocfs2_lock_res in order to get the status
      off of the lksb.  That's ugly.
      
      This changes stackglue to always pass the lksb as the argument to ast
      and bast functions.  The caller can always use container_of() to get the
      ocfs2_lock_res or user_dlm_lock_res.  The net effect to the caller is
      zero.  They still get back the lockres in their ast.  stackglue gets
      cleaner, and now can use the lksb itself.
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      a796d286
  4. 23 6月, 2009 1 次提交
    • J
      ocfs2: Provide the ocfs2_dlm_lvb_valid() stack API. · 1c520dfb
      Joel Becker 提交于
      The Lock Value Block (LVB) of a DLM lock can be lost when nodes die and
      the DLM cannot reconstruct its state.  Clients of the DLM need to know
      this.
      
      ocfs2's internal DLM, o2dlm, explicitly zeroes out the LVB when it loses
      track of the state.  This is not a standard behavior, but ocfs2 has
      always relied on it.  Thus, an o2dlm LVB is always "valid".
      
      ocfs2 now supports both o2dlm and fs/dlm via the stack glue.  When
      fs/dlm loses track of an LVBs state, it sets a flag
      (DLM_SBF_VALNOTVALID) on the Lock Status Block (LKSB).  The contents of
      the LVB may be garbage or merely stale.
      
      ocfs2 doesn't want to try to guess at the validity of the stale LVB.
      Instead, it should be checking the VALNOTVALID flag.  As this is the
      'standard' way of treating LVBs, we will promote this behavior.
      
      We add a stack glue API ocfs2_dlm_lvb_valid().  It returns non-zero when
      the LVB is valid.  o2dlm will always return valid, while fs/dlm will
      check VALNOTVALID.
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      Acked-by: NMark Fasheh <mfasheh@suse.com>
      1c520dfb
  5. 14 10月, 2008 1 次提交
    • M
      ocfs2: POSIX file locks support · 53da4939
      Mark Fasheh 提交于
      This is actually pretty easy since fs/dlm already handles the bulk of the
      work. The Ocfs2 userspace cluster stack module already uses fs/dlm as the
      underlying lock manager, so I only had to add the right calls.
      
      Cluster-aware POSIX locks ("plocks") can be turned off by the same means at
      UNIX locks - mount with 'noflocks', or create a local-only Ocfs2 volume.
      Internally, the file system uses two sets of file_operations, depending on
      whether cluster aware plocks is required. This turns out to be easier than
      implementing local-only versions of ->lock.
      Signed-off-by: NMark Fasheh <mfasheh@suse.com>
      53da4939
  6. 17 6月, 2008 3 次提交
  7. 18 4月, 2008 13 次提交