Junko IKEDA wrote:
Hi,
We are planning to make sf-ex into a quorum plugin,
but It might take a while because we aren't really familiar with it.
Your continued support will be greatly appreciated.
as for RA, last come, last served, let's see, the last node which can update
the reserve
Junko IKEDA wrote:
OK. I think you are mis-understanding the problem.
When the communication between Node A B is fine, you don't need any
kind of lock. Heartbeat itself can ensure the resource runs on one
selected
node, and on one node only.
sfex_lock() is just checking the status that
2007/8/13, Junko IKEDA [EMAIL PROTECTED]:
Assume we have 2 nodes.
1. Node A B reach step 3) in the same time.
2. sfex_lock on Node B is scheduled out due to some other reasons.
3. sfex_lock on Node A goes through step 3 to 6, and Node A holds
the lock now.
Node A is sure to hold
If Node B updates the lock status _at just the right moment_,
sfex_update() detects that the other node is trying to update its
status,
and it will be terminated with exit(2).
This time window is enough to destroy all data if you are bad luck ;-(
Node B is just updating its lock status,
Assume we have 2 nodes.
1. Node A B reach step 3) in the same time.
2. sfex_lock on Node B is scheduled out due to some other reasons.
3. sfex_lock on Node A goes through step 3 to 6, and Node A holds
the lock now.
Node A is sure to hold the lock at this moment.
sfex_lock() is going
: [Linux-ha-dev] Shared disk file Exclusiveness
controlprogramforHB2
2007/8/9, Junko IKEDA [EMAIL PROTECTED]:
Hi,
sorry, my previous answer was off the mark...
When 2 nodes reach there at the same time,
node A notices that the other node want to lock too, so give up lock
itself.
I only see
