04 Jan, 2012
3 commits
-
These new callbacks notify the dlm user about lock recovery.
GFS2, and possibly others, need to be aware of when the dlm
will be doing lock recovery for a failed lockspace member.In the past, this coordination has been done between dlm and
file system daemons in userspace, which then direct their
kernel counterparts. These callbacks allow the same
coordination directly, and more simply.Signed-off-by: David Teigland
-
Slot numbers are assigned to nodes when they join the lockspace.
The slot number chosen is the minimum unused value starting at 1.
Once a node is assigned a slot, that slot number will not change
while the node remains a lockspace member. If the node leaves
and rejoins it can be assigned a new slot number.A new generation number is also added to a lockspace. It is
set and incremented during each recovery along with the slot
collection/assignment.The slot numbers will be passed to gfs2 which will use them as
journal id's.Signed-off-by: David Teigland
-
Put all the calls to recovery barriers in the same function
to clarify where they each happen. Should not change any behavior.
Also modify some recovery debug lines to make them consistent.Signed-off-by: David Teigland
04 Feb, 2010
1 commit
-
Some comments misspell "truly"; this fixes them. No code changes.
Signed-off-by: Adam Buchbinder
Signed-off-by: Jiri Kosina
01 Dec, 2009
1 commit
-
Replace all GFP_KERNEL and ls_allocation with GFP_NOFS.
ls_allocation would be GFP_KERNEL for userland lockspaces
and GFP_NOFS for file system lockspaces.It was discovered that any lockspaces on the system can
affect all others by triggering memory reclaim in the
file system which could in turn call back into the dlm
to acquire locks, deadlocking dlm threads that were
shared by all lockspaces, like dlm_recv.Signed-off-by: David Teigland
16 May, 2009
1 commit
-
Change some GFP_KERNEL allocations to use either GFP_NOFS or
ls_allocation (when available) which the fs sets to GFP_NOFS.
The point is to prevent allocations from going back into the
cluster fs in places where that might lead to deadlock.Signed-off-by: David Teigland
15 May, 2009
1 commit
-
Make network connections to other nodes earlier, in the context of
dlm_recoverd. This avoids connecting to nodes from dlm_send where we
try to avoid allocations which could possibly deadlock if memory reclaim
goes into the cluster fs which may try to do a dlm operation.Signed-off-by: Christine Caulfield
Signed-off-by: David Teigland
22 Apr, 2008
1 commit
-
If a node is removed from a lockspace, and then added back before the
dlm is notified of the removal, the dlm will not detect the removal
and won't clear the old state from the node. This is fixed by using a
list of added nodes so the membership recovery can detect when a newly
added node is already in the member list.Signed-off-by: David Teigland
31 Jan, 2008
1 commit
-
Messages from nodes that are no longer members of the lockspace should be
ignored. When nodes are removed from the lockspace, recovery can
sometimes complete quickly enough that messages arrive from a removed node
after recovery has completed. When processed, these messages would often
cause an error message, and could in some cases change some state, causing
problems.Signed-off-by: David Teigland
10 Oct, 2007
1 commit
-
Introduce a per-lockspace rwsem that's held in read mode by dlm_recv
threads while working in the dlm. This allows dlm_recv activity to be
suspended when the lockspace transitions to, from and between recovery
cycles.The specific bug prompting this change is one where an in-progress
recovery cycle is aborted by a new recovery cycle. While dlm_recv was
processing a recovery message, the recovery cycle was aborted and
dlm_recoverd began cleaning up. dlm_recv decremented recover_locks_count
on an rsb after dlm_recoverd had reset it to zero. This is fixed by
suspending dlm_recv (taking write lock on the rwsem) before aborting the
current recovery.The transitions to/from normal and recovery modes are simplified by using
this new ability to block dlm_recv. The switch from normal to recovery
mode means dlm_recv goes from processing locking messages, to saving them
for later, and vice versa. Races are avoided by blocking dlm_recv when
setting the flag that switches between modes.Signed-off-by: David Teigland
Signed-off-by: Steven Whitehouse
14 Aug, 2007
1 commit
-
There's a memory leak in fs/dlm/member.c::dlm_add_member().
If "dlm_node_weight(ls->ls_name, nodeid)" returns < 0, then
we'll return without freeing the memory allocated to the (at
that point yet unused) 'memb'.
This patch frees the allocated memory in that case and thus
avoids the leak.Signed-off-by: Jesper Juhl
Signed-off-by: David Teigland
Signed-off-by: Steven Whitehouse
09 Jul, 2007
2 commits
-
Joining the lockspace should wait for the initial round of inter-node
config checks to complete before returning. This way, if there's a
configuration mismatch between the joining node and the existing nodes,
the join can fail and return an error to the application.Signed-off-by: David Teigland
Signed-off-by: Steven Whitehouse -
New features: lock timeouts and time warnings. If the DLM_LKF_TIMEOUT
flag is set, then the request/conversion will be canceled after waiting
the specified number of centiseconds (specified per lock). This feature
is only available for locks requested through libdlm (can be enabled for
kernel dlm users if there's a use for it.)If the new DLM_LSFL_TIMEWARN flag is set when creating the lockspace, then
a warning message will be sent to userspace (using genetlink) after a
request/conversion has been waiting for a given number of centiseconds
(configurable per node). The time warnings will be used in the future
to do deadlock detection in userspace.Signed-off-by: David Teigland
Signed-off-by: Steven Whitehouse
30 Nov, 2006
1 commit
-
Red Hat BZ 211914
With the new cluster infrastructure, dlm recovery for a node removal can
be aborted and restarted for a node addition. When this happens, the
restarted recovery isn't aware that it's doing recovery for the earlier
removal as well as the addition. So, it then skips the recovery steps
only required when nodes are removed. This can result in locks not being
purged for failed/removed nodes. The fix is to check for removed nodes
for which recovery has not been completed at the start of a new recovery
sequence.Signed-off-by: David Teigland
Signed-off-by: Steven Whitehouse
09 Aug, 2006
2 commits
-
To aid debugging, it's useful to be able to see what nodeid the dlm is
waiting on for a message reply.Signed-off-by: David Teigland
Signed-off-by: Steven Whitehouse -
When we abort one recovery to do another, break out of the ping_members()
routine more quickly, and wake up the dlm_recoverd thread more quickly
instead of waiting for it to time out.Signed-off-by: David Teigland
Signed-off-by: Steven Whitehouse
28 Apr, 2006
1 commit
-
When a node is removed from a lockspace configuration, close our
connection to it, clearing any remaining messages for it.Signed-off-by: David Teigland
Signed-off-by: Patrick Caulfield
Signed-off-by: Steven Whitehouse
20 Jan, 2006
1 commit
-
Signed-off-by: David Teigland
Signed-off-by: Steve Whitehouse
18 Jan, 2006
1 commit
-
This is the core of the distributed lock manager which is required
to use GFS2 as a cluster filesystem. It is also used by CLVM and
can be used as a standalone lock manager independantly of either
of these two projects.It implements VAX-style locking modes.
Signed-off-by: David Teigland
Signed-off-by: Steve Whitehouse