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

rpc-clnt: separate out connection_cleanup() from destroy()

2012-03-19T16:14:40+00:00

noticed that there are possibilities where one would like to do a
connection_cleanup() before destroying a RPC connection itself, also
current code is such that, rpc_clnt_connection_cleanup() does
rpc_clnt_ref() and unref(), creating a race window/double unref
possibilities in the code.

by separating out the functions, this race window/double fault can be
prevented.

Change-Id: I7ebd3392efa891232857b6db9108b0b19e40fc12
Signed-off-by: Amar Tumballi 
BUG: 802403
Reviewed-on: http://review.gluster.com/2979
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

protocol/client: Handle failures in lock self healing gracefully (part 1).

2012-03-19T16:05:58+00:00

During reopening of fd's and reacquiring of locks on the fd (after a
reconnect), a release on a fd on which reacquiring of locks is in progress
will free up fdctx. This patch will keep fdctx valid until the reacquiring
of locks is in progress.

Change-Id: I0464c751a5aa986abac0b72b48b261fceeba24e8
BUG: 795386
Signed-off-by: Mohammed Junaid 
Reviewed-on: http://review.gluster.com/2937
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Vijay Bellur

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

protocol/client: Avoid STACK_DESTROYing more than once in RELEASE fops.

2012-03-19T12:58:30+00:00

Change-Id: I435327c6133aa6739731dabddde860b0b43c1497
BUG: 804607
Signed-off-by: Vijay Bellur 
Reviewed-on: http://review.gluster.com/2978
Reviewed-by: Amar Tumballi 
Tested-by: Gluster Build System

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/client: replace STACK_UNWIND_STRICT macro with CLIENT_STACK_UNWIND,

2012-03-18T08:52:37+00:00

which does appropraite cleanup before unwinding.

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

rpc: don't unwind the fop in caller if client_submit_request fails

2012-03-18T08:52:04+00:00

client_submit_request guarantees that the cbkfn - which we pass to
it as argument - is called whenever there is a failure.

Change-Id: I0e8ce5a6b320246dc13ce4318b04739d38d183a3
BUG: 767359
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.com/2896
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
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