Hi all, [1] might have implications across different components in the stack. Your reviews are requested. <commit-msg> rpc : Change the way client uuid is built Problem: Today the main users of client uuid are protocol layers, locks, leases. Protocolo layers requires each client uuid to be unique, even across connects and disconnects. Locks and leases on the server side also use the same client uid which changes across graph switches and across file migrations. Which makes the graph switch and file migration tedious for locks and leases. As of today lock migration across graph switch is client driven, i.e. when a graph switches, the client reassociates all the locks(which were associated with the old graph client uid) with the new graphs client uid. This means flood of fops to get and set locks for each fd. Also file migration across bricks becomes even more difficult as client uuid for the same client, is different on the other brick. The exact set of issues exists for leases as well. Hence the solution: Make the migration of locks and leases during graph switch and migration, server driven instead of client driven. This can be achieved by changing the format of client uuid. Client uuid currently: %s(ctx uuid)-%s(protocol client name)-%d(graph id)%s(setvolume count/reconnect count) Proposed Client uuid: "CTX_ID:%s-GRAPH_ID:%d-PID:%d-HOST:%s-PC_NAME:%s-RECON_NO:%s" - CTX_ID: This is will be constant per client. - GRAPH_ID, PID, HOST, PC_NAME(protocol client name), RECON_NO(setvolume count) remains the same. With this, the first part of the client uuid, CTX_ID+GRAPH_ID remains constant across file migration, thus the migration is made easier. Locks and leases store only the first part CTX_ID+GRAPH_ID as their client identification. This means, when the new graph connects, the locks and leases xlator should walk through their database to update the client id, to have new GRAPH_ID. Thus the graph switch is made server driven and saves a lot of network traffic. Change-Id: Ia81d57a9693207cd325d7b26aee4593fcbd6482c BUG: 1369028 Signed-off-by: Poornima G <pgurusid@xxxxxxxxxx> Signed-off-by: Susant Palai <spalai@xxxxxxxxxx> </commit-msg> [1] http://review.gluster.org/#/c/13901/10/ regards, Raghavendra _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
