[Ocfs2-devel] [PATCH 0/6] nocontrold: Eliminating ocfs2_controld v4

[Ocfs2-devel] [PATCH 0/6] nocontrold: Eliminating ocfs2_controld v4

[Goldwyn Rodrigues]

Hi,

This is an effort of removing ocfs2_controld.pcmk and getting ocfs2 DLM
handling up to the times with respect to DLM (>=4.0.1) and corosync
(2.3.x). AFAIK, cman also is being phased out for a unified corosync
cluster stack.

fs/dlm performs all the functions with respect to fencing and node
management and provides the API's to do so for ocfs2. For all future
references, DLM stands for fs/dlm code.

The advantages are:
 + No need to run an additional userspace daemon (ocfs2_controld)
 + No contrrold devince handling and controld protocol
 + Shifting responsibilities of node management to DLM layer

For backward compatibility, we are keeping the controld handling code. Once
enough time has passed we can remove a significant portion of the code.

This feature requires modification in the userspace ocfs2-tools.
The changes can be found at:
https://github.com/goldwynr/ocfs2-tools branch: nocontrold
Currently, not many checks are present in the userspace code,
but that would change soon.

These changes were developed on linux-stable 3.11.y. However, the 
changes are applicable to the current upstream as well. If you wish
to give the entire kernel a spin, the link is:

https://github.com/goldwynr/linux-stable branch: nocontrold

Changes since v3:
* Added version negotiation using DLM lock
* Used strlcpy() instead of memcpy()

Changes since v2:
* Joel's comments: patch re-factoring

Changes since v1:
* Backward compatibility with ocfs2_controld

-- 
Goldwyn

[Ocfs2-devel] [PATCH 0/6] nocontrold: Eliminating ocfs2_controld v4

[Andrew Morton]

On Fri, 18 Oct 2013 09:44:54 -0500 Goldwyn Rodrigues <rgoldwyn@suse.de> wrote:

> This is an effort of removing ocfs2_controld.pcmk and getting ocfs2 DLM
> handling up to the times with respect to DLM (>=4.0.1) and corosync
> (2.3.x). AFAIK, cman also is being phased out for a unified corosync
> cluster stack.
> 
> fs/dlm performs all the functions with respect to fencing and node
> management and provides the API's to do so for ocfs2. For all future
> references, DLM stands for fs/dlm code.
> 
> The advantages are:
>  + No need to run an additional userspace daemon (ocfs2_controld)
>  + No contrrold devince handling and controld protocol
>  + Shifting responsibilities of node management to DLM layer
> 
> For backward compatibility, we are keeping the controld handling code. Once
> enough time has passed we can remove a significant portion of the code.
> 
> This feature requires modification in the userspace ocfs2-tools.
> The changes can be found at:
> https://github.com/goldwynr/ocfs2-tools branch: nocontrold
> Currently, not many checks are present in the userspace code,
> but that would change soon.
> 
> These changes were developed on linux-stable 3.11.y. However, the 
> changes are applicable to the current upstream as well. If you wish
> to give the entire kernel a spin, the link is:
> 
> https://github.com/goldwynr/linux-stable branch: nocontrold

I queued this up so it will get some linux-next exposure when Stephen
gets back to his desk.  But I don't feel I can take it further without
suitable input from the other ocfs2 developers (please).

[Ocfs2-devel] [PATCH 0/6] nocontrold: Eliminating ocfs2_controld v4

[Joel Becker]

On Fri, Oct 18, 2013 at 01:04:55PM -0700, Andrew Morton wrote:
> On Fri, 18 Oct 2013 09:44:54 -0500 Goldwyn Rodrigues <rgoldwyn@suse.de> wrote:
> 
> > This is an effort of removing ocfs2_controld.pcmk and getting ocfs2 DLM
> > handling up to the times with respect to DLM (>=4.0.1) and corosync
> > (2.3.x). AFAIK, cman also is being phased out for a unified corosync
> > cluster stack.
> > 
> > fs/dlm performs all the functions with respect to fencing and node
> > management and provides the API's to do so for ocfs2. For all future
> > references, DLM stands for fs/dlm code.
> > 
> > The advantages are:
> >  + No need to run an additional userspace daemon (ocfs2_controld)
> >  + No contrrold devince handling and controld protocol
> >  + Shifting responsibilities of node management to DLM layer
> > 
> > For backward compatibility, we are keeping the controld handling code. Once
> > enough time has passed we can remove a significant portion of the code.
> > 
> > This feature requires modification in the userspace ocfs2-tools.
> > The changes can be found at:
> > https://github.com/goldwynr/ocfs2-tools branch: nocontrold
> > Currently, not many checks are present in the userspace code,
> > but that would change soon.
> > 
> > These changes were developed on linux-stable 3.11.y. However, the 
> > changes are applicable to the current upstream as well. If you wish
> > to give the entire kernel a spin, the link is:
> > 
> > https://github.com/goldwynr/linux-stable branch: nocontrold
> 
> I queued this up so it will get some linux-next exposure when Stephen
> gets back to his desk.  But I don't feel I can take it further without
> suitable input from the other ocfs2 developers (please).

I thought I'd been pretty clear on the previous rounds.  The code had
some significant issues in its approach to compatibility (it wasn't).  I
haven't had a chance to look at this round yet, but I intend to soon.

Please do not forward this code without an explicit Acked-by from Mark
or I.

Joel

-- 

Viro's Razor:
	Any race condition, no matter how unlikely, will occur just
	often enough to bite you.

			http://www.jlbec.org/
			jlbec at evilplan.org

[Ocfs2-devel] [PATCH 0/6] nocontrold: Eliminating ocfs2_controld v4

[Goldwyn Rodrigues]

Hi Joel/Mark,

On 10/18/2013 06:06 PM, Joel Becker wrote:
> On Fri, Oct 18, 2013 at 01:04:55PM -0700, Andrew Morton wrote:
>> On Fri, 18 Oct 2013 09:44:54 -0500 Goldwyn Rodrigues <rgoldwyn@suse.de> wrote:
>>
>>> This is an effort of removing ocfs2_controld.pcmk and getting ocfs2 DLM
>>> handling up to the times with respect to DLM (>=4.0.1) and corosync
>>> (2.3.x). AFAIK, cman also is being phased out for a unified corosync
>>> cluster stack.
>>>
>>> fs/dlm performs all the functions with respect to fencing and node
>>> management and provides the API's to do so for ocfs2. For all future
>>> references, DLM stands for fs/dlm code.
>>>
>>> The advantages are:
>>>   + No need to run an additional userspace daemon (ocfs2_controld)
>>>   + No contrrold devince handling and controld protocol
>>>   + Shifting responsibilities of node management to DLM layer
>>>
>>> For backward compatibility, we are keeping the controld handling code. Once
>>> enough time has passed we can remove a significant portion of the code.
>>>
>>> This feature requires modification in the userspace ocfs2-tools.
>>> The changes can be found at:
>>> https://github.com/goldwynr/ocfs2-tools branch: nocontrold
>>> Currently, not many checks are present in the userspace code,
>>> but that would change soon.
>>>
>>> These changes were developed on linux-stable 3.11.y. However, the
>>> changes are applicable to the current upstream as well. If you wish
>>> to give the entire kernel a spin, the link is:
>>>
>>> https://github.com/goldwynr/linux-stable branch: nocontrold
>>
>> I queued this up so it will get some linux-next exposure when Stephen
>> gets back to his desk.  But I don't feel I can take it further without
>> suitable input from the other ocfs2 developers (please).
>
> I thought I'd been pretty clear on the previous rounds.  The code had
> some significant issues in its approach to compatibility (it wasn't).  I
> haven't had a chance to look at this round yet, but I intend to soon.
>
> Please do not forward this code without an explicit Acked-by from Mark
> or I.
>

Did you get a chance to review this?


-- 
Goldwyn

[Ocfs2-devel] [PATCH 0/6] nocontrold: Eliminating ocfs2_controld v4

[Mark Fasheh]

On Fri, Oct 18, 2013 at 04:06:59PM -0700, Joel Becker wrote:
> On Fri, Oct 18, 2013 at 01:04:55PM -0700, Andrew Morton wrote:
> > On Fri, 18 Oct 2013 09:44:54 -0500 Goldwyn Rodrigues <rgoldwyn@suse.de> wrote:
> > 
> > > This is an effort of removing ocfs2_controld.pcmk and getting ocfs2 DLM
> > > handling up to the times with respect to DLM (>=4.0.1) and corosync
> > > (2.3.x). AFAIK, cman also is being phased out for a unified corosync
> > > cluster stack.
> > > 
> > > fs/dlm performs all the functions with respect to fencing and node
> > > management and provides the API's to do so for ocfs2. For all future
> > > references, DLM stands for fs/dlm code.
> > > 
> > > The advantages are:
> > >  + No need to run an additional userspace daemon (ocfs2_controld)
> > >  + No contrrold devince handling and controld protocol
> > >  + Shifting responsibilities of node management to DLM layer
> > > 
> > > For backward compatibility, we are keeping the controld handling code. Once
> > > enough time has passed we can remove a significant portion of the code.
> > > 
> > > This feature requires modification in the userspace ocfs2-tools.
> > > The changes can be found at:
> > > https://github.com/goldwynr/ocfs2-tools branch: nocontrold
> > > Currently, not many checks are present in the userspace code,
> > > but that would change soon.
> > > 
> > > These changes were developed on linux-stable 3.11.y. However, the 
> > > changes are applicable to the current upstream as well. If you wish
> > > to give the entire kernel a spin, the link is:
> > > 
> > > https://github.com/goldwynr/linux-stable branch: nocontrold
> > 
> > I queued this up so it will get some linux-next exposure when Stephen
> > gets back to his desk.  But I don't feel I can take it further without
> > suitable input from the other ocfs2 developers (please).
> 
> I thought I'd been pretty clear on the previous rounds.  The code had
> some significant issues in its approach to compatibility (it wasn't).  I
> haven't had a chance to look at this round yet, but I intend to soon.

FYI this round seems to include backwards compat code.


> Please do not forward this code without an explicit Acked-by from Mark
> or I.

By forward I assume you mean to Linus? I agree this doesn't want to go
upstream yet but since the backwards compat code is in now I think it's
probably a good thing that this gets tested in linux-next.
	--Mark

--
Mark Fasheh

[Ocfs2-devel] [PATCH 0/6] nocontrold: Eliminating ocfs2_controld v4

[Mark Fasheh]

On Fri, Oct 18, 2013 at 09:44:54AM -0500, Goldwyn Rodrigues wrote:
> Hi,
> 
> This is an effort of removing ocfs2_controld.pcmk and getting ocfs2 DLM
> handling up to the times with respect to DLM (>=4.0.1) and corosync
> (2.3.x). AFAIK, cman also is being phased out for a unified corosync
> cluster stack.

Thanks again for doing this work. I'm about halfway done with the patches
when I write this but things seem to be coming along well.


> fs/dlm performs all the functions with respect to fencing and node
> management and provides the API's to do so for ocfs2. For all future
> references, DLM stands for fs/dlm code.
> 
> The advantages are:
>  + No need to run an additional userspace daemon (ocfs2_controld)
>  + No contrrold devince handling and controld protocol
>  + Shifting responsibilities of node management to DLM layer
> 
> For backward compatibility, we are keeping the controld handling code. Once
> enough time has passed we can remove a significant portion of the code.

Can you give us some brief details on how backwards compatibility was
tested? I have a feeling that it would alleviate some concerns we had about
that when the 1st series hit ocfs2-devel.
	--Mark

--
Mark Fasheh

[Ocfs2-devel] [PATCH 0/6] nocontrold: Eliminating ocfs2_controld v4

[Goldwyn Rodrigues]

On 11/03/2013 06:49 PM, Mark Fasheh wrote:
> On Fri, Oct 18, 2013 at 09:44:54AM -0500, Goldwyn Rodrigues wrote:
>> Hi,
>>
>> This is an effort of removing ocfs2_controld.pcmk and getting ocfs2 DLM
>> handling up to the times with respect to DLM (>=4.0.1) and corosync
>> (2.3.x). AFAIK, cman also is being phased out for a unified corosync
>> cluster stack.
>
> Thanks again for doing this work. I'm about halfway done with the patches
> when I write this but things seem to be coming along well.
>
>
>> fs/dlm performs all the functions with respect to fencing and node
>> management and provides the API's to do so for ocfs2. For all future
>> references, DLM stands for fs/dlm code.
>>
>> The advantages are:
>>   + No need to run an additional userspace daemon (ocfs2_controld)
>>   + No contrrold devince handling and controld protocol
>>   + Shifting responsibilities of node management to DLM layer
>>
>> For backward compatibility, we are keeping the controld handling code. Once
>> enough time has passed we can remove a significant portion of the code.
>
> Can you give us some brief details on how backwards compatibility was
> tested? I have a feeling that it would alleviate some concerns we had about
> that when the 1st series hit ocfs2-devel.

I ran the code with an unmodified ocfs2-tools/libdlm and it worked fine 
and I got the expected message of upgrading dlm/ocfs2-tools.

I checked the reverse (older kernel, newer tools) as well, and mount 
returned ESRCH because ocfs2_controld was not running.


-- 
Goldwyn

[Ocfs2-devel] [PATCH 0/6] nocontrold: Eliminating ocfs2_controld v4

[Mark Fasheh]

On Sun, Nov 03, 2013 at 09:48:07PM -0600, Goldwyn Rodrigues wrote:
> On 11/03/2013 06:49 PM, Mark Fasheh wrote:
>> On Fri, Oct 18, 2013 at 09:44:54AM -0500, Goldwyn Rodrigues wrote:
>>> Hi,
>>>
>>> This is an effort of removing ocfs2_controld.pcmk and getting ocfs2 DLM
>>> handling up to the times with respect to DLM (>=4.0.1) and corosync
>>> (2.3.x). AFAIK, cman also is being phased out for a unified corosync
>>> cluster stack.
>>
>> Thanks again for doing this work. I'm about halfway done with the patches
>> when I write this but things seem to be coming along well.
>>
>>
>>> fs/dlm performs all the functions with respect to fencing and node
>>> management and provides the API's to do so for ocfs2. For all future
>>> references, DLM stands for fs/dlm code.
>>>
>>> The advantages are:
>>>   + No need to run an additional userspace daemon (ocfs2_controld)
>>>   + No contrrold devince handling and controld protocol
>>>   + Shifting responsibilities of node management to DLM layer
>>>
>>> For backward compatibility, we are keeping the controld handling code. Once
>>> enough time has passed we can remove a significant portion of the code.
>>
>> Can you give us some brief details on how backwards compatibility was
>> tested? I have a feeling that it would alleviate some concerns we had about
>> that when the 1st series hit ocfs2-devel.
>
> I ran the code with an unmodified ocfs2-tools/libdlm and it worked fine and 
> I got the expected message of upgrading dlm/ocfs2-tools.
>
> I checked the reverse (older kernel, newer tools) as well, and mount 
> returned ESRCH because ocfs2_controld was not running.

Ok awesome - put this in your next 0/N e-mail please :) It's totally the
type of thing I'd love to see up front.

Thanks,
	--Mark

>
>
> -- 
> Goldwyn
--
Mark Fasheh