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 rese
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 status is going to win the righ
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
> 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 shows which node
2007/8/13, Junko IKEDA <[EMAIL PROTECTED]>:
> > > 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 a
> > 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 stat
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
> > 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()
re the control exclusively,
> > > lock_timeout should be longer enough than collision_timeout.
> > >
> > > Does that answer you?
> > >
> > > Thanks,
> > > Junko
> > >
> > >
> > > > -Original Message-
> >
ock_timeout should be longer enough than collision_timeout.
> >
> > Does that answer you?
> >
> > Thanks,
> > Junko
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf
you?
>
> Thanks,
> Junko
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Xinwei Hu
> > Sent: Thursday, August 09, 2007 8:58 PM
> > To: High-Availability Linux Development List
> > Subject: Re: [Lin
To: High-Availability Linux Development List
> Subject: Re: [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 ther
12 matches
Mail list logo
