glusterfs.git/xlators/protocol/server, branch v3.3.0qa30

protocol/server: Handle server send reply failure gracefully.

2012-03-19T15:11:43+00:00

Server send reply failure should not call server connection cleanup because
if a reconnection happens with in the grace-timeout the connection object is
reused. We must cleanup only on grace-timeout.

Change-Id: I7d171a863382646ff392031c2b845fe4f0d3d5dc
BUG: 803365
Signed-off-by: Mohammed Junaid 
Reviewed-on: http://review.gluster.com/2947
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

print bound_xl only once in server statedump

2012-03-19T12:51:28+00:00

since, currently there is only one bound_xl for
all connection objects, it does not make sense
to print the bound_xl for every conn object.

Change-Id: Iaf4a170fe63fb7e80133c449a20f298f0e86364c
BUG: 765495
Signed-off-by: Rahul C S 
Reviewed-on: http://review.gluster.com/2975
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

Logs: Improved logs in lock/unlock execution path

2012-03-18T08:53:41+00:00

Statedump will now start showing the lk-owner of the stack.

Change-Id: I9f650ce9a8b528cd626c8bb595c1bd1050462c86
BUG: 803209
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.com/2968
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

protocol/server: Clear internal locks on disconnect

2012-03-18T08:09:43+00:00

If there is a disconnect observed on the client when the
inode/entry unlock is issued, but the reconnection to server
happens with in the grace-time period the inode/entry lk will
live and the unlock will never come from that client.
The internal locks should be cleared on disconnect.

Change-Id: Ib45b1035cfe3b1de381ef3b331c930011e7403be
BUG: 803209
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.com/2966
Reviewed-by: Anand Avati 
Tested-by: Gluster Build System

protocol/server: send forget on the renamed inode

2012-03-18T08:00:01+00:00

If rename is given on a file "a" to "b" ("b" is already existing file),
then after rename, the inode for "b" would still be in the inode table
and would not get forget (for fuse client, the fuse kernel module would
send, but on server forget will not come on that inode), thus leading
to inode leak even when the mount point is empty.

To avoid that before doing inode rename, unlink the previous inode that
"b" is pointing to and send forget on that, if "b" is the last dentry
for that inode.

Change-Id: Ie4dcc39ea190ee8f28029b4d7661df576d9cf319
BUG: 799833
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.com/2874
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Anand Avati

mgmt/glusterd : volume set validation fixes

2012-03-18T07:52:40+00:00

This is the new version of the patch by Kaushik at review.gluster.com/699

The following new option types have been introduced:
 * GF_OPTION_TYPE_INTERNET_ADDRESS_LIST
 * GF_OPTION_TYPE_PRIORITY_LIST
 * GF_OPTION_TYPE_SIZE_LIST
and option types of several options in translators have been updated to use the
new types.

valid_internet_address(), valid_ipv4_address() & valid_ipv6_address() functions
has been updated for * wildcard matching. Previously used standalone wildcard
address checking functions have been removed.

Changes have been done to stripe translator to correctly set, update and use
stripe-blocksize. Also minimum value for block-size has been set to 16KB.

Change-Id: I2aa484ff695f6a915a8fc9a9f965cf0344f41d59
BUG: 765248
Signed-off-by: Kaushal M 
Reviewed-on: http://review.gluster.com/2899
Tested-by: Gluster Build System 
Reviewed-by: Shishir Gowda 
Reviewed-by: Anand Avati

protocol/server: memory leak fixes.

2012-03-18T06:39:07+00:00

Change-Id: I203832d9d52373f068f90e30dc7672329d65bbea
BUG: 803675
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.com/2954
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Anand Avati

protocol/server: add and remove the transports from the list, inside the lock

2012-03-18T06:27:26+00:00

Till now for graph changes, glusterfs client used to remember the old graph
also. Hence the transport object on the server corresponding the old graph
never received disconnect. But now since the graph cleanup is happening,
transport on the server side gets disconnect for the cleaned up graph.

Server maintains, all the transports in a list. But addition of the new
transport to the list, or removal of the transport from the list is not
happening within the lock. Thus if a thread is accessing a transport
(in cases of statedump, where each transprt's information is dumped),
and the server gets a disconnect on that transport, then it leads to
segfault of the process.

To avoid it do the list (of transports) manipulation inside the lock.

Change-Id: I50e8389d5ec8f1c52b8d401ef8c8ddd262e82548
BUG: 803815
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.com/2958
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

protocol/server: Avoid race in add/del locker, connection_cleanup

2012-03-18T06:22:24+00:00

conn->ltable address keeps changing in
server_connection_cleanup every time it is called.
i.e. New ltable is created every time it is called.
Here is the race that happened:
---------------------------------------------------
thread-1                        | thread-2
add_locker is called with       |
conn->ltable. lets call the     |
ltable address lt1              |
                                | connection cleanup is called
                                | and do_lock_table_cleanup is
                                | triggered for lt1. locker
                                | lists are splice_inited under
                                | the lt1->lock
lt1 adds the locker under       |
lt1->lock (lets call this l1)   |
                                | GF_FREE(lt1) happens in
                                | do_lock_table_cleanup

The locker l1 that is added just before lt1 is freed will never
be cleared in the subsequent server_connection_cleanups as there
does not exist a reference to the locker. The stale lock remains
in the locks xlator even though the transport on which it was
issued is destroyed.

Change-Id: I0a02f16c703d1e7598b083aa1057cda9624eb3fe
BUG: 787601
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.com/2957
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Amar Tumballi 
Reviewed-by: Anand Avati

protocol/server: Remove connection from conf->conns w.o. race

2012-03-13T11:58:45+00:00

1) Adding the connection to conf->conns used to
happen in conf->mutex, but removing happened under conn->lock.
Fixed that as below.
When the connection object is created conn's ref, bind_ref count
is set to '1'. For bind_ref ref/unref happens under conf->mutex
whenever server_connection_get, put is called.
When bind_ref goes to '0' connection object is removed from
conf->conns under conf->mutex.  After it is removed from the list,
conn_unref is called outside the conf->mutex.
conn_ref/unref still happens under conn->lock.

2) Fixed races in server_connection_cleaup in grace_timer_handler
and server_setvolume.

Change-Id: Ie7b63b10f658af909a11c3327066667f5b7bd114
BUG: 801675
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.com/2911
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Vijay Bellur