From: Goldwyn Rodrigues <rgoldwyn@suse.de>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 0/6] nocontrold: Eliminating ocfs2_controld v4
Date: Thu, 31 Oct 2013 08:15:31 -0500 [thread overview]
Message-ID: <527257F3.2080704@suse.de> (raw)
In-Reply-To: <20131018230658.GC4490@localhost>
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
next prev parent reply other threads:[~2013-10-31 13:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-18 14:44 [Ocfs2-devel] [PATCH 0/6] nocontrold: Eliminating ocfs2_controld v4 Goldwyn Rodrigues
2013-10-18 20:04 ` Andrew Morton
2013-10-18 23:06 ` Joel Becker
2013-10-31 13:15 ` Goldwyn Rodrigues [this message]
2013-11-04 0:51 ` Mark Fasheh
2013-11-04 0:49 ` Mark Fasheh
2013-11-04 3:48 ` Goldwyn Rodrigues
2013-11-04 22:08 ` Mark Fasheh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=527257F3.2080704@suse.de \
--to=rgoldwyn@suse.de \
--cc=ocfs2-devel@oss.oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.