[Ocfs2-devel] [PATCH 0/5] nocontrold: Eliminating ocfs2_controld v3

[Ocfs2-devel] [PATCH 0/5] nocontrold: Eliminating ocfs2_controld v3

[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, though they 
are applicable at the current upstream as well. If you want to give
the entire kernel a spin, the link is:

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

Changes since v2:
* Joel's comments: patch re-factoring
* No need to safeguard cluster_stack

Changes since v1:
* Backward compatibility with ocfs2_controld
* Moved cluster_stack change restriction to dlm code

-- 
Goldwyn

[Ocfs2-devel] [PATCH 0/5] nocontrold: Eliminating ocfs2_controld v3

[Lars Marowsky-Bree]

On 2013-10-03T00:48:55, Goldwyn Rodrigues <rgoldwyn@suse.de> wrote:

Hi Goldwyn,

just a minor comment:

> 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 we add this to Documentation/fs/ocfs2.txt, or maybe print a one-time
message on activating the deprecated mode with an intended removal date?
(I'd propose end-of-2014.)

And, perhaps, a compile-time option to disable this earlier, so that
users can choose the stacks they want to build the kernel with.


Thanks,
    Lars

-- 
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 21284 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

[Ocfs2-devel] [PATCH 0/5] nocontrold: Eliminating ocfs2_controld v3

[Andrew Morton]

On Thu, 3 Oct 2013 00:48:55 -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, though they 
> are applicable at the current upstream as well. If you want to give
> the entire kernel a spin, the link is:
> 
> https://github.com/goldwynr/linux-stable branch: nocontrold
> 
> Changes since v2:
> * Joel's comments: patch re-factoring
> * No need to safeguard cluster_stack
> 
> Changes since v1:
> * Backward compatibility with ocfs2_controld
> * Moved cluster_stack change restriction to dlm code

I'm not really sure what to do with this patchset.  It's too deep for
me to merge on my own cognizance so I am dependent upon reviews and
acks from ocfs2 specialists before I can move forward.  Where are we at
with that?

[Ocfs2-devel] [PATCH 0/5] nocontrold: Eliminating ocfs2_controld v3

[Goldwyn Rodrigues]

On 10/03/2013 06:25 AM, Lars Marowsky-Bree wrote:
> On 2013-10-03T00:48:55, Goldwyn Rodrigues <rgoldwyn@suse.de> wrote:
>
> Hi Goldwyn,
>
> just a minor comment:
>
>> 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 we add this to Documentation/fs/ocfs2.txt, or maybe print a one-time
> message on activating the deprecated mode with an intended removal date?
> (I'd propose end-of-2014.)

We already print a message in dmesg saying:
printk(KERN_NOTICE "ocfs2: You seem to be using an older "
                    "version of dlm_controld and/or ocfs2-tools."
                    " Please consider upgrading.\n");

Adding a date to this should not be a problem.

>
> And, perhaps, a compile-time option to disable this earlier, so that
> users can choose the stacks they want to build the kernel with.
>

This would a be a couple of ifdef's in user_cluster_connect(). What do 
other ocfs2 developers feel about this?


-- 
Goldwyn

[Ocfs2-devel] [PATCH 0/5] nocontrold: Eliminating ocfs2_controld v3

[Joel Becker]

On Fri, Oct 04, 2013 at 10:01:34AM -0500, Goldwyn Rodrigues wrote:
> On 10/03/2013 06:25 AM, Lars Marowsky-Bree wrote:
> > On 2013-10-03T00:48:55, Goldwyn Rodrigues <rgoldwyn@suse.de> wrote:
> >
> > And, perhaps, a compile-time option to disable this earlier, so that
> > users can choose the stacks they want to build the kernel with.
> >
> 
> This would a be a couple of ifdef's in user_cluster_connect(). What do 
> other ocfs2 developers feel about this?

We already allow building of o2cb/user stacks via .config.  So on that
note it isn't terribly different.

lmb, why do you want to enforce non-controld?  Shouldn't it be just fine
to not install controld and let the filesystem detect a modern enough
fs/dlm?

Joel

> 
> 
> -- 
> Goldwyn
> 
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-devel

-- 

Life's Little Instruction Book #306

	"Take a nap on Sunday afternoons."

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

[Ocfs2-devel] [PATCH 0/5] nocontrold: Eliminating ocfs2_controld v3

[Lars Marowsky-Bree]

On 2013-10-07T17:06:09, Joel Becker <jlbec@evilplan.org> wrote:

> We already allow building of o2cb/user stacks via .config.  So on that
> note it isn't terribly different.
> 
> lmb, why do you want to enforce non-controld?  Shouldn't it be just fine
> to not install controld and let the filesystem detect a modern enough
> fs/dlm?

It's mostly an issue of what the distribution kernels wish to support.
One less variable to control for.

We either get that choice upstream or carry an out of tree patch, hence
my proposal to do it upstream ;-)



Regards,
    Lars

-- 
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 21284 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde