glusterfs.git/xlators/protocol/server/src/server.h, branch v3.8.13

protocol/server: Implementation of compound fop

2016-05-02T01:05:31+00:00

Change-Id: I981258afa527337dd2ad33eecba7fc8084238e6d
BUG: 1303829
Signed-off-by: Anuradha Talur 
Reviewed-on: http://review.gluster.org/14137
Smoke: Gluster Build System 
Reviewed-by: Niels de Vos 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

protocol: add setactivelk () fop

2016-05-02T01:04:52+00:00

Change-Id: I60fe2d59c454095febce4c0fbef87a2dad9636e4
BUG: 1326085
Signed-off-by: Susant Palai 
Reviewed-on: http://review.gluster.org/14013
Smoke: Gluster Build System 
Reviewed-by: Niels de Vos 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

Protocol: Add lease fop

2016-04-30T05:37:39+00:00

Change-Id: I64c361d3e4ae86d57dc18bb887758d044c861237
BUG: 1319992
Signed-off-by: Poornima G 
Reviewed-on: http://review.gluster.org/11597
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Rajesh Joseph 
Reviewed-by: Pranith Kumar Karampuri

server: send lookup on root inode when itable is created

2016-03-30T19:39:42+00:00

 * xlators like quota, marker, posix_acl can cause problems
   if inode-ctx are not created.
   sometime these xlarors may not get lookup on root inode
   with below cases
   1) client may not send lookup on root inode (like NSR leader)
   2) if the xlators on one of the bricks are not up,
      and client sending lookup during this time: brick
      can miss the lookup
   It is always better to make sure that there is one lookup
   on root. So send a first lookup when the inode table is created

 * When sending lookup on root, new inode is created, we need to
   use itable->root instead

Change-Id: Iff2eeaa1a89795328833a7761789ef588f11218f
BUG: 1320818
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/13837
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Jeff Darcy

protocol client/server: Fix client-server handshake

2016-03-10T17:24:33+00:00

Problem:
Currently on a successful connection between protocol
server and client, the protocol client initiates a
CHILD_UP event in the client stack. At this point in
time, only the connection between server and client is
established, and there is no guarantee that the server
side stack is ready to serve requests.

It works fine now, as most server side translators are
not dependent on any other factors, before being able
to serve requests today and hence they are up by the time
the client stack translators receive the CHILD_UP (initiated
by client handshake).

The gap here is exposed when certain server side translators
like NSR-Server for example, have a couple of protocol clients
as their child(connecting them to other bricks), and they
can't really serve requests till a quorum of their children are
up. Hence these translators should defer sending CHILD_UP
till they have enough children up, and the same needs to be
propagated to the client stack translators.

Fix:
Maintain a child_up variable in both the protocol client
and protocol server translators. The protocol server should
update this value based on the CHILD_UP and CHILD_DOWN
events it receives from the translators below it. On receiving
such an event it should forward that event to the client.
The protocol client on receiving such an event should forward
it up the client stack, thereby letting the client translators
correctly know that the server is up and ready to serve.

The clients connecting later(long after a server has initialized
and processed it's CHILD_UP events), will receive a child_up status
as part of the handshake, and based on the status of the server's
child_up, can either propagate a CHILD_UP event or defer it.

Change-Id: I0807141e62118d8de9d9cde57a53a607be44a0e0
BUG: 1312845
Signed-off-by: Avra Sengupta 
Reviewed-on: http://review.gluster.org/13549
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

protocol: implement seek() FOP

2016-02-04T17:31:32+00:00

Network protocol extensions for the seek() FOP. The format is based on
the SEEK procedure in NFSv4.2.

Change-Id: I060768a8a4b9b1c80f4a24c0f17d630f7f028690
BUG: 1220173
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/11482
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Jeff Darcy

server/protocol: option for dynamic authorization of client permissions

2015-10-05T05:31:05+00:00

problem:
assuming gluster volume is already mounted (for gfapi: say client transport
connection has already established), now if somebody change the volume
permissions say *.allow | *.reject for a client, gluster should allow/terminate
the client connection based on the fresh set of volume options immediately,
but in existing scenario neither we have any option to set this behaviour nor
we take any action until and unless we remount the volume manually

solution:
Introduce 'dynamic-auth' option (default: on).
If 'dynamic-auth' is 'on' gluster will perform dynamic authentication to
allow/terminate client transport connection immediately in response to
*.allow | *.reject volume set options, thus if volume permissions have changed
for a particular client (say client is added to auth.reject list), his
transport connection to gluster volume will be terminated immediately.

Change-Id: I6243a6db41bf1e0babbf050a8e4f8620732e00d8
BUG: 1245380
Signed-off-by: Prasanna Kumar Kalever 
Reviewed-on: http://review.gluster.org/12229
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G

protocol-client/server: Fix incorrect grace-timeout value in logs

2015-09-03T15:18:33+00:00

When grace-timer is initialized via server/client init,
the default or reconfigured value for grace-timeout is
displayed incorrectly in both server and client logs.
This is because we use gf_time_fmt() to format this
grace-timeout value with gf_timefmt_s as the time format
as shown below:

gf_time_fmt (timestr, sizeof timestr, conf->grace_ts.tv_sec,
                     gf_timefmt_s);

gf_timefmt_s format is a wrapper for %s format specification
used in strftime library call which populates the number
of seconds since the Epoch [1970-01-01 00:00:00 +0000 (UTC)].
But this particular format is dependent on timezone
[1970-01-01 05:30:00 +0530 (IST)]and thus displayed incorrectly
in logs.

Example:
For IST with default grace-timeout value 10, it is displayed
as -19790 which is calculated as follows,
1970-01-01 00:00:10 - 1970-01-01 05:30:00 = -19790 seconds.

Change-Id: I1bdf5d12b2167323f86f0ca52a37ffb316b3f0a2
BUG: 1227667
Signed-off-by: Anoop C S 
Reviewed-on: http://review.gluster.org/11930
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra Talur 
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy

protocol/server: forget the inodes which got ENOENT in lookup

2015-08-21T05:02:45+00:00

If a looked up object is removed from the backend, then upon getting a
revalidated lookup on that object ENOENT error is received. protocol/server
xlator handles it by removing dentry upon which ENOENT is received. But the
inode associated with it still remains in the inode table, and whoever does
nameless lookup on the gfid of that object will be able to do it successfully
despite the object being not present.

For handling this issue, upon getting ENOENT on a looked up entry in revalidate
lookups, protocol/server should forget the inode as well.

Though removing files directly from the backend is not allowed, in case of
objects corrupted due to bitrot and marked as bad by scrubber, objects are
removed directly from the backend in case of replicate volumes, so that the
object is healed from the good copy. For handling this, the inode of the bad
object removed from the backend should be forgotten. Otherwise, the inode which
knows the object it represents is bad, does not allow read/write operations
happening as part of self-heal.

Change-Id: I23b7a5bef919c98eea684aa1e977e317066cfc71
BUG: 1238188
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11489
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G

protocol/server: fail setvolume if any of xlators is not initialized yet

2015-07-02T11:11:52+00:00

We can only start recieving fops only when all xlators in graph are
initialized.

Change-Id: Id79100bab5878bb2518ed133c1118554fbb35229
BUG: 1236945
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/11490
Reviewed-by: Krishnan Parthasarathi 
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Venky Shankar 
Reviewed-by: Raghavendra Bhat