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

server: send lookup on root inode when itable is created

2016-03-31T12:15:32+00:00

This is a backport of http://review.gluster.org/#/c/13837

 * 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 

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

server/protocol: option for dynamic authorization of client permissions

2015-10-13T16:05:37+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.

Backport of:
> 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 
> (cherry picked from commit 84e90b756566bc211535a8627ed16d4231110ade)

Change-Id: If7e5c9be912412ea388391ef406ee2c8bedb26b8
BUG: 1271065 
Signed-off-by: Prasanna Kumar Kalever 
Reviewed-on: http://review.gluster.org/12343
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G

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

2015-08-21T11:48:48+00:00

                 Backport of http://review.gluster.org/11489

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: I268eeaf37969458687425187be6622347a6cc1f1
BUG: 1255604
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11973
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G

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

2015-07-02T11:14:09+00:00

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

Change-Id: Id79100bab5878bb2518ed133c1118554fbb35229
BUG: 1214169
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/11504
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System

epoll: Adding the ability to configure epoll threads

2015-02-07T21:23:03+00:00

Add the ability to configure the number of event threads
for various gluster services.

Currently with the multi thread epoll patch, it is possible
to have more than one thread waiting on socket activity and
processing the same. This thread count is currently static,
which this commit makes dynamic.

The current services which use IO path, i.e brick processes,
any client process (nfs, FUSE, gfapi, heal,
rebalance, etc.a), gain 2 set parameters to control the number
of threads that are processing events. These settings are,
  - client.event-threads 
  - server.event-threads 

The client setting affects the client graph consumers, and the
server setting affects the brick processes. These are processed
and inited/reconfigured using the client/server protocol xlators.

Other services (say glusterd) would need to extend similar
configuration settings to take advantage of multi threaded event
processing.

At present glusterd is not enabled with this commit, as it does not
stand to gain from this multi-threading (as I understand it).

Change-Id: Id8422fc57a9f95a135158eb6477ccf9d3c9ea4d9
BUG: 1104462
Signed-off-by: Shyam 
Reviewed-on: http://review.gluster.org/9488
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

rpc: implement server.manage-gids for group resolving on the bricks

2014-05-09T19:22:39+00:00

The new volume option 'server.manage-gids' can be enabled in
environments where a user belongs to more than the current absolute
maximum of 93 groups. This option triggers the following behavior:

1. The AUTH_GLUSTERFS structure sent by GlusterFS clients (fuse, nfs or
   libgfapi) will contain only one (1) auxiliary group, instead of
   a full list. This reduces network usage and prevents problems in
   encoding the AUTH_GLUSTERFS structure which should fit in 400 bytes.
2. The single group in the RPC Calls received by the server is replaced
   by resolving the groups server-side. Permission checks and similar in
   lower xlators are applied against the full list of groups where the
   user belongs to, and not the single auxiliary group that the client
   sent.

Change-Id: I9e540de13e3022f8b63ff893ecba511129a47b91
BUG: 1053579
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/7501
Tested-by: Gluster Build System 
Reviewed-by: Santosh Pradhan 
Reviewed-by: Harshavardhana 
Reviewed-by: Anand Avati

glusterd/snapshot : Clean up of old barrier code.

2014-04-30T09:13:26+00:00

As a new barrier translator is introduced, we dont require
the old barrier code. Hence cleaning thar up.

Change-Id: Ieedca6f33a746898f0d2332fda1f1d4c86fff98f
BUG: 1061685
Signed-off-by: Sachin Pandit 
Reviewed-on: http://review.gluster.org/7577
Tested-by: Gluster Build System 
Reviewed-by: Kaushal M 
Reviewed-by: Vijaikumar Mallikarjuna 
Reviewed-by: Vijay Bellur

glusterd: Ping timer implmentation

2014-04-29T21:23:51+00:00

This patch refactors the existing client ping timer implementation, and makes
use of the common code for implementing both client ping timer and the
glusterd ping timer.

A new gluster rpc program for ping is introduced. The ping timer is only
started for peers that have this new program. The deafult glusterd ping
timeout is 30 seconds. It is configurable by setting the option
'ping-timeout' in glusterd.vol .

Also, this patch introduces changes in the glusterd-handshake path. The client
programs for a peer are now set in the callback of dump_versions, for both
the older handshake and the newer op-version handshake. This is the only place
in the handshake process where we know what programs a peer supports.

Change-Id: I035815ac13449ca47080ecc3253c0a9afbe9016a
BUG: 1038261
Signed-off-by: Vijaikumar M 
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/5202
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

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

client_t: phase 2, refactor server_ctx and locks_ctx out

2013-10-31T16:32:50+00:00

remove server_ctx and locks_ctx from client_ctx directly and store as
into discrete entities in the scratch_ctx

hooking up dump will be in phase 3

BUG: 849630
Change-Id: I94cea328326db236cdfdf306cb381e4d58f58d4c
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/5678
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati