[Gluster-devel] Server-side AFR + Failover and mixed server/client-side AFR

[gordan at bobich.net]

On Wed, 7 May 2008, Krishna Srinivas wrote:

>>>>>>>  Is this an issue in server-side-only AFR? I have two servers
>> which
>>>>>>> are also clients of themselves, and they both list their local >
>> subvolume first and
>>>>>>> remote subvolume second. Is this a problem? What are the possible
>>>>>>> consequences of this?
>>>>>>
>>>>>>  It will be a problem. The "first" subvol is always the "lock"
>> server.
>>>>>>  Consider a case where you are creating a file simultaneously
>>>>>>  on two clients, only one of them should succeed. If AFR's
>>>>>>  subvols order are not same, chances are that both client
>>>>>>  returns success for file creation with same name.
>>>>>>
>>>>>>
>>>>>
>>>>> Hence you have "option read-subvlume" to speeden the
>>>>> read() calls so that it can be done from local subvol.
>>>>>
>>>>>
>>>>
>>>>  So, what happens if the "lock" server is the one that goes down?  Will
>> that
>>>> render the whole AFR cluster inoperable, at least for writes?
>>>>
>>>>
>>>
>>> If first server is down, the second one is tried and so on. The cluster
>> remains
>>> operable.
>>>
>>
>>  Does the lock state remain for the locks when the primary/lock server dies?
>> If so, how?
>
> If the server on which the lock was held goes down, the lock is lost.
> Finally the
> client will try to unlock on that server (it remembers) and fails.
>
> In case client dies, the server removes all the locks held by that client.

Right, that's what I thought. Is a distributed and redundant lock-tracking 
mechanism planned?

Gordan