[ClusterLabs Developers] New challenges with corosync 3/kronosnet + pacemaker

Klaus Wenninger kwenning at redhat.com
Mon Feb 12 05:28:21 EST 2018

On 02/12/2018 09:21 AM, Christine Caulfield wrote:
> On 12/02/18 08:04, Jan Friesse wrote:
>> Ken Gaillot napsal(a):
>>> On Fri, 2018-02-09 at 12:52 -0500, Digimer wrote:
>>>> On 2018-02-09 03:27 AM, Jan Pokorný wrote:
>>>>> Hello,
>>>>> there is certainly whole can of these worms, put first that crosses
>>>>> my mind: performing double (de)compression on two levels of
>>>>> abstraction
>>>>> in the inter-node communication is not very clever, to put it
>>>>> mildly.
>>>>> So far, just pacemaker was doing that for itself under certain
>>>>> conditions, now corosync 3 will have it's iron in this fire through
>>>>> kronosnet, too.  Perhaps something to keep in mind to avoid
>>>>> exercises in futility.
>>>> Can pacemaker be told to not do compression? If not, can that be
>>>> added
>>>> in pacemaker v2?
>>> Or better yet, is there some corosync API call we can use to determine
>>> whether corosync/knet is using compression?
>> Sure. Just read "totem.knet_compression_model" cmap key. If it doesn't
>> exists or is "none", compression is disabled.
> Which is the default.

Didn't check for current size limits but I remember (looong time ago) when
setting the limit for when pacemaker starts compressing too large some
interface-limit between pacemaker and corosync was hit.
Just for the case that disabling compression in pacemaker might lead
to hitting such limits ...


> Chrissie
> _______________________________________________
> Developers mailing list
> Developers at clusterlabs.org
> http://lists.clusterlabs.org/mailman/listinfo/developers

More information about the Developers mailing list