- 26 Jun, 2006 40 commits
-
-
Kurt Hackel authored
Signed-off-by:
Kurt Hackel <kurt.hackel@oracle.com> Signed-off-by:
Mark Fasheh <mark.fasheh@oracle.com>
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
We cannot restart recovery. Once we begin to recover a node, keep the state of the recovery intact and follow through, regardless of any other node deaths that may occur. Signed-off-by:
-
Kurt Hackel authored
If the previous master of the recovery lock dies, let calc_usage take it down completely and let the caller completely redo the dlmlock() call. Otherwise, there will never be an opportunity to re-master the lockres and recovery wont be able to progress. Signed-off-by:
-
Kurt Hackel authored
Use the existing structure for blocking migrations when ASTs are pending to achieve the same result. If we can catch the assert before it goes on the wire, just cancel it and let the migration continue. Signed-off-by:
-
Kurt Hackel authored
Now we never change the owner of a lock resource until unmount or node death. This will be re-enabled once some issues in the algorithm used have been resolved. Signed-off-by:
-
Kurt Hackel authored
In dlmlock_remote(), do not call purge_lockres until the lock resource actually changes. otherwise, the mastery info on the lockres will go away underneath the caller. Signed-off-by:
-
Kurt Hackel authored
When mastering non-recovery lock resources, additional time was frequently needed to allow the disk heartbeat to catch up with the network timeout. the recovery lock resource is time critical and avoids this path. Signed-off-by:
-
Kurt Hackel authored
Recovery will spin in dlm_pre_master_reco_lockres if we do not ignore timed-out network responses from dead nodes. Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Change behavior of dlm_restart_lock_mastery() when a node goes down. Dump all responses that have been collected and start over. Signed-off-by:
-
Kurt Hackel authored
This is an error on the sending side, so gracefully error out on the receiving end. Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Immediately purge a lockress that the local node is not the master of. Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Makes it easier for the recovery process to deal with node death. Signed-off-by:
-
Kurt Hackel authored
Take a reference on lockres structures while they are on the recovery list. Signed-off-by:
-
Kurt Hackel authored
handle errors during lock assert master by either killing self or other node Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Mark Fasheh authored
Don't wait until the AST will be fired to do the LVB copy into the lock resource. Signed-off-by: -
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
The check for an empty lvb should check the entire buffer not just the first byte. Signed-off-by:
-
Kurt Hackel authored
Signed-off-by:
-
Kurt Hackel authored
Recovery may have happened and it may now be mastered locally. Signed-off-by:
-
Kurt Hackel authored
Otherwise we risk starving other threads. Signed-off-by:
-
Mark Fasheh authored
Reported by Andrew Morton. Signed-off-by: -
Joel Becker authored
The OCFS2 DLM allocates a number of pages for a hash to lookup locks. There was a bug where a PAGE_SIZE bigger than the hash size (eg, 64K pages) would result in zero pages allocated. Signed-off-by:
Joel Becker <joel.becker@oracle.com> Signed-off-by:
-
