posix locking on OCFS2

[Richard Sharpe]

On Sun, Nov 23, 2014 at 1:39 PM, Rowland Penny <repenny241155 at gmail.com> wrote:
> On 23/11/14 20:23, Michael Adam wrote:
>>
>> On 2014-11-23 at 18:23 +0000, Rowland Penny wrote:
>>>
>>> On 23/11/14 17:34, Michael Adam wrote:
>>>>
>>>> The number in parentheses is the manual page section.
>>>> For instance, there is a command line tool called flock
>>>> (section 1). And the C-function flock (section 2).
>>>> This parenthesis notation is just a convenient way to
>>>> identify one, i.e. flock(1) refers to the command line tool
>>>> and flock(2) refers to the C-function. You can look at the
>>>> corresponding man pages with "man 1 flock" and "man 2 flock".
>>>> And so on.
>>>
>>> I understand about the numbers in parentheses (brackets for lesser
>>> mortals
>>> like me) ;-)
>>
>> Oh, hints like these are always very valuable for me.
>> Not being a native speaker (which might account for
>> being something else than a "lesser mortal"... ;-)
>> I learned that:
>>
>> - () are parentheses
>> - [] are brackets
>> - {} are braces
>>
>> So I was not trying to use especially sophisticated
>> language, but just what I learned... ;)
>>
>> http://en.wikipedia.org/wiki/Bracket seems to support
>> that, but also tells me that "bracket" is the general term
>> including the above and that [] are also called square
>> brackets and {} curly brackets... You never stop learning... :)
>>
>>> but what about when the brackets are empty?
>>
>> You don't need to take it to seriously.
>> I guess this should just make it clear that it
>> is a function that is being referred to.
>>
>>>>> According to Steve, CTDB does not work,
>>>>
>>>> Since those who should know confirmed that OCFS2
>>>> has sufficient support for fcntl locks to support
>>>> ctdb's recovery lock, I assume that steve has
>>>> a misconfiguration of some kind. Just stating that
>>>> it does not work is by the way not precise enough.
>>>
>>> OK, I understand what you are saying, but I seem to remember Steve asking
>>> for help with this some time ago.
>>> All I want to do is get the documentation on the wiki updated correctly,
>>> so
>>> that users can follow it and end up with the results they require.
>>
>> Right, but I think David was absolutely right in reverting
>> your note on the wiki, since
>> a) There was afaik no evidence/detail for ctdb not working on ocfs2.
>> b) The notice from the people that do run samba + ctdb + ocfs2
>>     that it works as expected. And these are the people who also
>>     ship this combo in their distro (David and others).
>>
>> So, your effort to improve the wiki documentation is
>> highly appreciated, Rowland, but in this case, I am
>> afraid the change was premature.
>>
>> Cheers - Michael
>
> I understand that it would seem that I prematurely updated the wiki, that is
> why I am now trying to get to the root of the problem, and it would seem
> that there is a problem. Just where the problem is, is not going to be found
> by berating someone who tried CTDB and failed because they couldn't get/find
> the information to fix it. He did find a workaround and has said so, that is
> why he doesn't have the info, but he has asked someone, who might have the
> info, if they can provide it.

I think your update is correct. There is ample evidence that as long
as you correctly configure GFS and OCFS2 you will have posix locking
(AKA fcntl locks) which is what ctdb uses to ensure that there is only
one copy of the recovery daemon running at any one time in the cluster
(also called split-brain prevention.)

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)