glusterfs.git/rpc/rpc-transport/rdma/src, branch bug-deprecated

build: FreeBSD 11-Current causes libtool to fail with '-shared'

2014-12-12T09:21:49+00:00

Thanks for Markiyan Kushnir  for
reporting this

Change-Id: I7f637295c7c2d54c33a4c16e29daf0b518874911
BUG: 1111774
Signed-off-by: Harshavardhana 
Reviewed-on: http://review.gluster.org/9251
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

rdma:client process will hang if server is started to send

2014-11-18T10:38:33+00:00

the request before completing connection establishment

in rdma, client and server will interchange their available
buffers during the handshake to post incoming messages.
Initially the available buffer is set to one, for the first message
during handshake,when first message is received, quota for
the buffer will set to proper value. So before receiving the message
if server started to send the message, then the reserverd buffer for
handshake will be utilised, then the handshake will fail because
of lack of buffers. So we should block sending messages by server
before proper connection establishment.

Change-Id: I68ef44998f5df805265d3f42a5df7c31cb57f136
BUG: 1158746
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/9003
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

rdma: client connection establishment takes more time

2014-11-18T08:50:13+00:00

For rdma type only volume client connection establishment
with server takes more than three seconds. Because for
tcp,rdma type volume, will have 2 ports one for tcp and
one for rdma, tcp port is stored with brickname and rdma
port is stored as "brickname.rdma" during pamap_sighin.
During the handshake when trying to get the brick port
for rdma clients, since we are not aware of server
transport type, we will append '.rdma' with brick name.
So for tcp,rdma volume there will be an entry with
'.rdma', but it will fail for rdma type only volume.
So we will try again, this time without appending '.rdma'
using a flag variable need_different_port, and it will succeed,
but the reconnection happens only after 3 seconds.
In this patch for rdma only type volume 
we will append '.rdma' during the pmap_signin. So during the
handshake we will get the correct port for first try itself.
Since we don't need to retry , we can remove the
need_different_port flag variable.

Change-Id: Ie8e3a7f532d4104829dbe995e99b35e95571466c
BUG: 1153569
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/8934
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

rdma:rdma fuse mount hangs for tcp,rdma volumes if brick is down.

2014-11-18T07:30:55+00:00

When we try to mount a tcp,rdma volume as rdma
transport using FUSE protocol, then mount will
hang if the brick is down. When we kill a process,
signal will be received in glusterfsd process and
it will call pmap_signout with port listening on tcp only.
In case of the tcp,rdma there will be two ports,
and port which is listening for rdma will not
called for sign out. 
So the mount process will try to connect to a port
which is not open and it will keep trying to connect.
This patch will call pmap_signout for rdma port also,
So when mount tries to get the brick port,it will fail.

Change-Id: I23676f65f96eb90b69b76478f7a21412a6aba70f
BUG: 1143886
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/8762
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

rdma: glusterd crash if rdma_disconnect is called as soon as connect a request.

2014-11-14T12:03:59+00:00

we are initializing connection in server side immediately after
rdma_accept is called. But we are delaying adding the transport
to listener list until getting RDMA_CM_EVENT_ESTABLISHED event.
Before getting this event if disconnect is called glusterd will
try to remove the transport from list which is not added. So if
the list is empty it causes a glusterd crash . In this patch we
will call the function to initialize the connection as soon as
rdma_accept is called.

Change-Id: I019480297a85349ede3101ee9c7c1596dc5c73e2
Signed-off-by: Mohammed Rafi KC 
BUG: 1164079
Reviewed-on: http://review.gluster.org/8925
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

rdma:setting rdma REUSEADDR flag to rdma id.

2014-11-14T05:57:41+00:00

When we restart the process, it will go TIME_WAIT state to make sure that
all the data in the transport is successfully delivered. REUSEADDR 
allows server to bind to an address which is in TIME_WAIT state.

Change-Id: Ic7deb0d7442c29494fe088598ffe9c87977c04ff
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/9005
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

rdma: mount hangs for rdma type transport.

2014-10-08T08:44:36+00:00

rdma transport type mount will hang if there is a delay
in network to receive,we will set transport as connected
if we get an event type RDMA_CM_EVENT_ESTABLISHED,
we cannot assure whether client or server will get the
event first, the only condition is that the side which
sends the first request should wait for the event.
If client gets the event first, then it sends DUMP request,
in server side the request will reach, but it will reject
the rpc request since it didn't get the RDMA_CM_EVENT_ESTABLISHED.
So in server we will set the connected flag as soon
as rdma_accept is called.

Change-Id: Iac5845e3592666daa575c727822889779b5bd203
BUG: 1146492
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/8850
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

rdma: glusterfsd SEGV at volume start

2014-08-13T17:31:53+00:00

glusterfsd NULL ptr deref in proto/server: get_frame_from_request()
with 'transport rdma' volume

no test case, our regression test framework doesn't have Infiniband.
If it did, the test case would be to create a 'transport rdma' volume,
start it, and create/write/read/delete files on the volume.

Change-Id: I91a6956bdf8f61f3853e0c0951744460ba138576
BUG: 1129708
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/8479
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

build: MacOSX Porting fixes

2014-04-24T21:41:48+00:00

git@forge.gluster.org:~schafdog/glusterfs-core/osx-glusterfs

Working functionality on MacOSX

 - GlusterD (management daemon)
 - GlusterCLI (management cli)
 - GlusterFS FUSE (using OSXFUSE)
 - GlusterNFS (without NLM - issues with rpc.statd)

Change-Id: I20193d3f8904388e47344e523b3787dbeab044ac
BUG: 1089172
Signed-off-by: Harshavardhana 
Signed-off-by: Dennis Schafroth 
Tested-by: Harshavardhana 
Tested-by: Dennis Schafroth 
Reviewed-on: http://review.gluster.org/7503
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

rdma: correct some spelling mistakes

2014-04-17T22:06:05+00:00

Change-Id: Ib7018aa8a79d36ab942516457a79039cb3e67355
BUG: 1088849
Reported-by: Patrick Matthäi 
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/7498
Reviewed-by: Vikhyat Umrao 
Tested-by: Gluster Build System