[Gluster-users] How Fatal? "Server and Client lk-version numbers are not same, reopening the fds"

[harry mangalam]

Despite Joe Landman's sage advice to the contrary, I'm trying to
convince an IPoIB volume to service requests from a GbE client via
some /etc/hosts manipulation. (This may or may not be related to the
automount problems we're having as well.)

This has worked (and continues to work) well on another cluster with a
slightly older version of gluster - the 3.3.0qa42 version on both server
and client).

In the following case the servers are on IPoIB (net 10.2.x.x) and GbE
(10.1.x.x) and can ping back and forth on their respective networks to
all the clients and servers.  The gluster volume was created using the
IPoIB network and numbers:

Volume Name: gl
Type: Distribute
Volume ID: 21f480f7-fc5a-4fd8-a084-3964634a9332
Status: Started
Number of Bricks: 8
Transport-type: tcp,rdma
Bricks:
Brick1: bs2:/raid1
Brick2: bs2:/raid2
Brick3: bs3:/raid1
Brick4: bs3:/raid2
Brick5: bs4:/raid1
Brick6: bs4:/raid2
Brick7: bs1:/raid1
Brick8: bs1:/raid2
Options Reconfigured:
nfs.disable: on
performance.io-cache: on
performance.quick-read: on
performance.io-thread-count: 64
auth.allow: 10.2.*.*,10.1.*.*

using 3.3 servers on SciLi 6.2 and  3.3.0qa42 clients. When trying to
mount the gluster volume on an ethernet client, coerced into believing
that the server is on ethernet using /etc/hosts manipulations, it
doesn't complete the mount, failing rapidly with the following log:
<http://pastie.org/4123348>.   The server log doesn't seem to show
anything.

There are repeated references to "Server and Client lk-version numbers
are not same, reopening the fds".  

Is this a fatal error or a side effect?

How important is having exactly matching versions?