glusterfs.git/tests/features, branch v3.10.0

tests: reenable trash.t

2017-02-13T13:19:39+00:00

Now that the underlying bug has been fixed (by d97e63d0) we can allow
the test to run again.

Backport of:
> Change-Id: If9736d142f414bf9af5481659c2b2673ec797a4b
> BUG: 1420434
> Reviewed-on: https://review.gluster.org/16584

Change-Id: I44edf2acfd5f9ab33bdc95cc9fc981e04c3eead1
BUG: 1418091
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/16598
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Shyamsundar Ranganathan 
CentOS-regression: Gluster Build System

core: run many bricks within one glusterfsd process

2017-02-02T00:54:58+00:00

This patch adds support for multiple brick translator stacks running in
a single brick server process.  This reduces our per-brick memory usage
by approximately 3x, and our appetite for TCP ports even more.  It also
creates potential to avoid process/thread thrashing, and to improve QoS
by scheduling more carefully across the bricks, but realizing that
potential will require further work.

Multiplexing is controlled by the "cluster.brick-multiplex" global
option.  By default it's off, and bricks are started in separate
processes as before.  If multiplexing is enabled, then *compatible*
bricks (mostly those with the same transport options) will be started in
the same process.

Backport of:
> Change-Id: I45059454e51d6f4cbb29a4953359c09a408695cb
> BUG: 1385758
> Reviewed-on: https://review.gluster.org/14763

Change-Id: I4bce9080f6c93d50171823298fdf920258317ee8
BUG: 1418091
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/16496
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan

core: remove experimental xlators and associated tests

2017-01-24T13:25:58+00:00

experimental xlators not included in 3.10

Change-Id: I547480ee5e7912664784643e436feb198b6d16d0
BUG: 1415866
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: https://review.gluster.org/16447
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee 
Reviewed-by: Shyamsundar Ranganathan

jbr: Sending rollback from failed fop to fdl

2016-11-08T19:25:25+00:00

In case of a failed fop, the failure is detected
by the leader in the jbr-server in two places. First
during a quorum check of +ve responses when it
receives responses from all the followers. At this
point if the fop hasn't been successfully journaled
at a quorum of followers (as in there is no merit in
trying the fop in the leader as the quorum will never
be met), then we fail the fop.

Also if this quorum is met, then the fop is tried on
the leader, and after the leader completes the fop
a quorum check similar to the previous one is done
again, this time including the leaders outcome. If
quorum is not met, then we fail the fop.

In both these cases, when the fop fails we send a -ve
ack to the client. With this patch, now we will also
send a rollback through a GF_FOP_IPC to all the followers(and
also to the leader in the second case of failure). This
rollback will contain the index and term number of the
fop which failed. This will be recorded in the respective
journals of the bricks and will be used to rollback the
fop on that brick later.

A subsequent write, and it's respective rollback would
look something like the following in the journal.

The trusted.jbr.term and trusted.jbr.index present in the
dict of both the logs, relate them, and the presence of
"rollback-fop" in the dict of IPC indicates that it is a
rollback fop, and the value 13(stands for GF_FOP_WRITE)
indicates what kind of rollback operation it is.

=== GF_FOP_WRITE
fd = 
vector = <158 bytes>
offset = 0 (0x0)
flags = 32769 (0x8001)
xdata = dict {
 trusted.jbr.term = 0 <2 bytes>
 trusted.jbr.index = 4 <2 bytes>
}
=== GF_FOP_IPC
xdata = dict {
 trusted.jbr.term = 0 <2 bytes>
 trusted.jbr.index = 4 <2 bytes>
 rollback-fop = 13 <3 bytes>
}

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

tests: disable lock_revocation.t on NetBSD

2016-08-31T12:15:59+00:00

This has been consistently causing hangs in NetBSD machines. I have not
been able to debug the issue and we have merge deadline for 3.9. It
would be better to disable this for now.

Change-Id: I8c63940aa26f78dd9994bb63293a5757835ec52b
BUG: 1369401
Signed-off-by: Raghavendra Talur 
Reviewed-on: http://review.gluster.org/15374
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

glusterd: clean up old port and allocate new one on every restart

2016-08-04T04:43:34+00:00

GlusterD as of now was blindly assuming that the brick port which was already
allocated would be available to be reused and that assumption is absolutely
wrong.

Solution : On first attempt, we thought GlusterD should check if the already
allocated brick ports are free, if not allocate new port and pass it to the
daemon. But with that approach there is a possibility that if PMAP_SIGNOUT is
missed out, the stale port will be given back to the clients where connection
will keep on failing. Now given the port allocation always start from base_port,
if everytime a new port has to be allocated for the daemons, the port range will
still be under control. So this fix tries to clean up old port using
pmap_registry_remove () if any and then goes for pmap_registry_alloc ()

Change-Id: If54a055d01ab0cbc06589dc1191d8fc52eb2c84f
BUG: 1221623
Signed-off-by: Atin Mukherjee 
Reviewed-on: http://review.gluster.org/15005
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Avra Sengupta

features/locks: Add lock revocation functionality to posix locks translator

2016-07-18T09:30:38+00:00

Summary:
- Motivation: Prevents cluster instability by mis-behaving clients
causing bricks to OOM due to inode/entry lock pile-ups.
- Adds option to strip clients of entry/inode locks after N seconds
- Adds option to clear ALL locks should the revocation threshold get hit
- Adds option to clear all or granted locks should the max-blocked
threshold get hit (can be used in combination w/ revocation-clear-all).
- Options are:
features.locks-revocation-secs
features.locks-revocation-clear-all [on/off]
features.locks-revocation-max-blocked
- Adds monkey-locking option to ignore 1% of unlock requests (dev only)
features.locks-monkey-unlocking [on/off]
- Adds logging to indicate revocation event & reason

Test Plan:
First you will need TWO fuse mounts for this repro. Call them /mnt/patchy1 & /mnt/patchy2.

1. Enable monkey unlocking on the volume:
gluster vol set patchy features.locks-monkey-unlocking on

2. From the "patchy1", use DD or some other utility to begin writing to a file,
eventually the dd will hang due to the dropped unlocked requests. This now
simulates the broken client. Run:

for i in {1..1000};do dd if=/dev/zero of=/mnt/patchy1/testfile bs=1k count=10;done'

...this will eventually hang as the unlock request has been lost.

3. Goto another window and setup the mount "patchy2" @ /mnt/patchy2, and
observe that 'echo "hello" >> /mnt/patchy2/testfile" will hang due to the
inability of the client to take out the required lock.

4. Next, re-start the test this time enabling lock revocation; use a timeout of
2-5 seconds for testing:
'gluster vol set patchy features.locks-revocation-secs <2-5>'

5. Wait 2-5 seconds before executing step 3 above this time. Observe that this
time the access to the file will succeed, and the writes on patchy1 will
unblock until they hit another failed unlock request due to
"monkey-unlocking".

BUG: 1350867
Change-Id: I814b9f635fec53834a26db634d1300d9a61057d8
Signed-off-by: Pranith Kumar K
Reviewed-on: http://review.gluster.org/14816
NetBSD-regression: NetBSD Build System
Reviewed-by: Krutika Dhananjay
CentOS-regression: Gluster Build System
Smoke: Gluster Build System

api: use versioned symbols for minor ABI change

2016-06-15T01:30:21+00:00

No need to expand the API/ABI. E.g., see how glfs_lookupat
changed between 3.7.0 and 3.7.4 IIRC

(I originally argued against versioning the library. I wanted
to just add new functions as they were needed, as was initially
done for glfs_ipc and glfs_ipc_xd in the master branch for 4.0.
But others strongly wanted versioning.)

Having made the decision to use versioning, I believe we should
continue. At least until we have a public decision that we're
no longer going to use versioning.

Change-Id: I0c3b2c1cbb297ae2b2864b647c224922987d74ad
Signed-off-by: Kaleb S KEITHLEY 
Reviewed-on: http://review.gluster.org/14717
Reviewed-by: Shyamsundar Ranganathan 
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

glusterd: volgen and volume set changes for leases

2016-06-03T04:58:43+00:00

Add leases xlator in volgen and also add corresponding volume set options

Change-Id: Ic5de50cdb87eaf6a833e739bc7e08fecbeca3de3
BUG: 1319992
Signed-off-by: Poornima G 
Reviewed-on: http://review.gluster.org/11722
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Smoke: Gluster Build System 
Reviewed-by: Atin Mukherjee

features/locks: Implement mandatory locks

2016-05-02T11:18:44+00:00

Initial change to fix/enable the mandatory locking support in GlusterFS
as per the following design:

https://review.gluster.org/#/c/12014/

Accordingly 'locks.mandatory-locking' option is available as part of this
change which will accept one among the following values:

* off
* file
* forced
* optimal

See design doc for more details

Change-Id: I14c489b3f8af5ebcbfa155a03f0c175e9558ac46
BUG: 762184
Signed-off-by: Anoop C S 
Reviewed-on: http://review.gluster.org/9768
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Poornima G 
Reviewed-by: Raghavendra Talur 
Reviewed-by: Rajesh Joseph 
Reviewed-by: Pranith Kumar Karampuri