glusterfs.git/rpc/rpc-lib/src/protocol-common.h, branch v3.6.0alpha1

glusterd: Fail peer probe/detach commands when peer detach is ongoing

2014-06-16T17:03:12+00:00

Change-Id: Ifd8099bc235eb395e8fd9ead3197bef71c78042b
BUG: 1109812
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/8079
Reviewed-by: Atin Mukherjee 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

Get snapshot info dynamically via new rpc and infra for snapview-server to refresh snaplist

2014-06-15T17:33:23+00:00

BUG: 1105439
Change-Id: I4bb312a53d88f6f4955e69a3ef2b4955ec17f26d
Signed-off-by: Anand Subramanian 
Reviewed-on: http://review.gluster.org/8001
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

libgfapi: Added support to fetch volume info from glusterd and store in glfs object.

2014-05-11T09:47:42+00:00

Defined new APIs in the libgfapi module, given a glfs object,
 * to send handshake RPC call to glusterd process to fetch UUID of the volume
 * store it in the glusterfs_context linked to the glfs object.
 * to parse UUID from its cannonical string format into 16-byte array
   before sending it to the libgfapi users.

Defined a RPC call in glusterd which can be used to query volume related
info by other processes using 'clnt_handshake_procs'.

Note - Currently this RPC call to glusterd process is used only to fetch UUID.
But it can be extended to get other volume related structures as well.

In addition to the above, defined a new variable to keep track of such handshake
RPCs still in progress to make sure all the corresponding RPC callbacks have been
processed before libgfapi returns the glfs object initialized.

Also bumping up the GFAPI current version number since there is a new API
"glfs_get_volume_id" defined and exposed by libgfapi as part of these changes.

Change-Id: I303f76d7177d32d25bdb301b1dbcf5cd73f42807
BUG: 1090363
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/7218
Reviewed-by: Anand Avati 
Reviewed-by: Harshavardhana 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

glusterd : Volname, brickpath & volfpath length validation

2014-05-03T15:20:06+00:00

While creating a volume and adding a brick validation for _POSIX_PATH_MAX is
done on absolute pathname instead of relative pathname due to which a brickpath
having less than _POSIX_PATH_MAX may also fail the validation if the directory
length is greater than (_POSIX_PATH_MAX -strlen(brickpath/volume name).

Also this fix addresses one cli response message correction which says the
volume file is too long instead of brick path is too long (when brickpath
length validation doesn't fail and vol file length validation fails.)

It is also important to note that with the current design of volfile naming, it
can not be guranteed that volname and brickpath can have max of _POSIX_PATH_MAX
characters.

Change-Id: I1283d1f9dea96ae797620002c8723719f26a866d
BUG: 1085330
Signed-off-by: Atin Mukherjee 
Reviewed-on: http://review.gluster.org/7420
Reviewed-by: Niels de Vos 
Reviewed-by: Krishnan Parthasarathi 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

cli: Add a cli command to enable/disable barrier

2014-04-29T16:37:32+00:00

This patch adds a new
 'gluster volume barrier  {enable|disable}'
cli command. This helps in testing the brick op code path when testing
the barrier xlator.
This patch can be reverted later if not required for end users.
Change-Id: Icd86a2d13e7f276dda1ecbb2593d60638ece7dcd
BUG: 1060002
Signed-off-by: Kaushal M 
Reviewed-on: http://review.gluster.org/6958
Reviewed-by: Krishnan Parthasarathi 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

glusterd: Add a barrier brick-op

2014-04-29T16:37:08+00:00

This patch introduces a new 'barrier' brick-op which will be used to
activate/deactivate the barriering on the bricks. This includes
barriering in the barrier xlator and in the changelog xlator. All the
required code has been including a bricks select function, a payload
builder and a brick-op handler.

Change-Id: I91d9d77f691c2e89823f7dc4e84900ec40dc4dd2
BUG: 1060002
Signed-off-by: Kaushal M 
Reviewed-on: http://review.gluster.org/6943
Reviewed-by: Krishnan Parthasarathi 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

glusterd/snapshot: Compare and update snapshots during peer handshake

2014-04-28T11:02:22+00:00

During a peer-handshake, after the volumes have synced, and the list of
missed snapshots have synced, the node will perform the pending deletes
and restores on this list. At this point, the current snapshot list in
the node will be updated, and hence in case of conflicts arising during
snapshot handshake, the peer hosting the bricks will be given precedence
Likewise, if there will be a conflict, and both peers will be in the same
state, i.e either both would be hosting bricks or both would not be hosting
bricks, then a decision can't be taken and a peer-reject will happen.

glusterd_compare_and_update_snap() implements the following algorithm to
perform the above task:
Step  1: Start.
Step  2: Check if the peer is missing a delete on the said snap.
         If yes, goto step 6.
Step  3: Check if there is a conflict between the peer's data and the
         local snap. If no, goto step 5.
Step  4: As there is a conflict, check if both the peer and the local nodes
         are hosting bricks. Based on the results perform the following:
         Peer Hosts Bricks    Local Node Hosts Bricks       Action
               Yes                     Yes                Goto Step 7
               No                      No                 Goto Step 7
               Yes                     No                 Goto Step 8
               No                      Yes                Goto Step 6
Step  5: Check if the local node is missing the peer's data.
         If yes, goto step 9.
Step  6: It's a no-op. Goto step 10
Step  7: Peer Reject. Goto step 10
Step  8: Delete local node's data.
Step  9: Accept Peer Data.
Step 10: Stop

Change-Id: I79be0f0f5f2a4f5c72277a4e77c2be732af432e1
BUG: 1061685
Signed-off-by: Avra Sengupta 
Reviewed-on: http://review.gluster.org/7525
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi 
Reviewed-by: Rajesh Joseph 
Reviewed-by: Atin Mukherjee 
Reviewed-by: Vijay Bellur

glusterd/snapshot-handshake: Perform handshake of missed_snaps_list.

2014-04-26T06:53:42+00:00

In a handshake, create a union of the missed_snap_lists of the two peers.
If an entry is present, its no op.
If an entry is pendng, and the peer entry is done, mark own entry as done.
If an entry is done, and the peer ertry is pending, its a no-op.
If its a new entry, add it.

Change-Id: Idbfa49cc34871631ba8c7c56d915666311024887
BUG: 1061685
Signed-off-by: Avra Sengupta 
Reviewed-on: http://review.gluster.org/7453
Tested-by: Gluster Build System 
Reviewed-by: Rajesh Joseph 
Reviewed-by: Vijay Bellur

gluster: GlusterFS Volume Snapshot Feature

2014-04-11T23:29:17+00:00

This is the initial patch for the Snapshot feature. Current patch
includes following features:
* Snapshot create
* Snapshot delete
* Snapshot restore
* Snapshot list
* Snapshot info
* Snapshot status
* Snapshot config

Change-Id: I2f46920c0d61c515f6a60e0f8b46fff886d9f6a9
BUG: 1061685
Signed-off-by: shishir gowda 
Signed-off-by: Sachin Pandit 
Signed-off-by: Vijaikumar M 
Signed-off-by: Raghavendra Bhat 
Signed-off-by: Rajesh Joseph 
Signed-off-by: Joseph Fernandes 
Signed-off-by: Avra Sengupta 
Reviewed-on: http://review.gluster.org/7128
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

glusterd: Volume locks and transaction specific opinfos

2014-02-11T07:25:40+00:00

With this patch we are replacing the existing cluster-wide
lock taken on glusterds across the cluster, with volume locks
which are also taken on glusterds across the cluster, but are
volume specific. So with the volume locks we are able to perform
more than one gluster operation at the same time, as long as the
operations are being performed on different volumes.

We maintain a global list of volume-locks (using a dict for a list)
where the key is the volume name, and which saves the uuid of the
originator glusterd. These locks are held and released per volume
transaction.

In order to acheive multiple gluster operations occuring at the
same time, we also separate opinfos in the op-state-machine, as a
part of this patch. To do so, we generate a unique transaction-id
(uuid) per gluster transaction. An opinfo is then associated with
this transaction id, which is used throughout the transaction. We
maintain a run-time global list(using a dict) of transaction-ids,
and their respective opinfos to achieve this.

Upstream Feature Page: http://www.gluster.org/community/documentation/index.php/Features/glusterd-volume-locks

Change-Id: Iaad505a854bac8de8f83beec0357eb6cde3f7ea8
BUG: 1011470
Signed-off-by: Avra Sengupta 
Reviewed-on: http://review.gluster.org/5994
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur