From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christine Caulfield Date: Mon, 21 Sep 2009 09:50:20 +0100 Subject: [Cluster-devel] [PATCH] dlm: fix lowcomms_connect_node for sctp In-Reply-To: <20090918213754.GA18138@redhat.com> References: <20090918193906.GB4340@redhat.com> <20090918213754.GA18138@redhat.com> Message-ID: <4AB73E4C.2060000@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On 18/09/09 22:37, David Teigland wrote: > On Fri, Sep 18, 2009 at 02:39:06PM -0500, David Teigland wrote: >> The recently added dlm_lowcomms_connect_node() from >> 391fbdc5d527149578490db2f1619951d91f3561 does not work >> when using SCTP instead of TCP. The sctp connection code >> has nothing to do without data to send. Check for no data >> in the sctp connection code and do nothing instead of >> triggering a BUG. Also have connect_node() do nothing >> when the protocol is sctp. That patch looks sane to me > With this patch I can use sctp (single interface), but I'm getting these > alloc_fd errors (which seem harmless enough) have you seen them before? Yes I have seen them before. At the time I put them down to either a bug in SCTP or an artifact of the way it works, because lowcomms isn't explicitly allocating any new FDs here - they are hidden behind the sctp layer and passed back to use later on in process_sctp_notification(). > Also, gfs is *really* slow using sctp! I haven't done any benchmarks for ages. The last time some were done I was told that SCTP was actually faster than TCP! ... though that was with the 'old' DLM. I put this down to the fact that SCTP is optimised for streaming because of its origins. If it's now slowed down a lot it's probably worth investigating further - I really wouldn't expect the single-home configurations to differ by very much. Chrissie.