glusterfs.git/xlators/mgmt/glusterd/src, branch v3.13.2

cluster/afr: Adding option to take full file lock

2018-01-19T14:24:52+00:00

Problem:
In replica 3 volumes there is a possibilities of ending up in split
brain scenario, when multiple clients writing data on the same file
at non overlapping regions in parallel.

Scenario:
- Initially all the copies are good and all the clients gets the value
  of data readables as all good.
- Client C0 performs write W1 which fails on brick B0 and succeeds on
  other two bricks.
- C1 performs write W2 which fails on B1 and succeeds on other two bricks.
- C2 performs write W3 which fails on B2 and succeeds on other two bricks.
- All the 3 writes above happen in parallel and fall on different ranges
  so afr takes granular locks and all the writes are performed in parallel.
  Since each client had data-readables as good, it does not see
  file going into split-brain in the in_flight_split_brain check, hence
  performs the post-op marking the pending xattrs. Now all the bricks
  are being blamed by each other, ending up in split-brain.

Fix:
Have an option to take either full lock or range lock on files while
doing data transactions, to prevent the possibility of ending up in
split brains. With this change, by default the files will take full
lock while doing IO. If you want to make use of the old range lock
change the value of "cluster.full-lock" to "no".

Change-Id: I7893fa33005328ed63daa2f7c35eeed7c5218962
BUG: 1535438
Signed-off-by: karthik-us

glusterd: Nullify pmap entry for bricks belonging to same port

2018-01-09T13:59:10+00:00

Commit 30e0b86 tried to address all the stale port issues glusterd had
in case of a brick is abruptly killed. For brick multiplexing case
because of a bug the portmap entry was not getting removed. This patch
addresses the same.

>mainline patch : https://review.gluster.org/#/c/19119/

Change-Id: Ib020b967a9b92f1abae9cab9492f0cacec59aaa1
BUG: 1530449
Signed-off-by: Atin Mukherjee

glusterd: connect to an existing brick process when qourum status is NOT_APPLICABLE_QUORUM

2018-01-09T13:58:47+00:00

First of all, this patch reverts commit 635c1c3 as the same is causing a
regression with bricks not coming up on time when a node is rebooted.
This patch tries to fix the problem in a different way by just trying to
connect to an existing running brick when quorum status is not
applicable.

>mainline patch : https://review.gluster.org/#/c/19134/

Change-Id: I0efb5901832824b1c15dcac529bffac85173e097
BUG: 1511293
Signed-off-by: Atin Mukherjee

write-behind: Allow trickling-writes to be configurable

2017-12-20T14:15:36+00:00

This is the undisputed/trivial part of Shreyas' patch
he attached to https://bugzilla.redhat.com/1364740 (of
which the current bug is a clone).

We need more evaluation for the page_size and window_size
bits before taking them on.

Change-Id: Iaa0b9a69d35e522b77a52a09acef47460e8ae3e9
BUG: 1428060
Co-authored-by: Shreyas Siravara 
Signed-off-by: Csaba Henk

glusterd: Free up svc->conn on volume delete

2017-12-07T04:49:26+00:00

Daemons like snapd, tierd and gfproxyd are maintained on per volume
basis and on a volume delete we should destroy the rpc connection
established for them.

>mainline patch : https://review.gluster.org/#/c/18957/

Change-Id: Id1440e39da07b990fdb9b207df18da04b1ca8014
BUG: 1523046
Signed-off-by: Atin Mukherjee 
(cherry picked from commit 36ce4c614a3391043a3417aa061d0aa16e60b2d3)

posix: Change GD_OP_VERSION to 3_13_0 from 3_12_0 for storage.reserve

2017-12-01T16:13:16+00:00

Problem: Change GD_OP_VERSION to 3_13_0 from 3_12_0 for option storage.reserve

Solution: Actually feature was merged in 3.13.0 branch so GD_OP_VERSION needs
         to change from 3_12_0 to 3_13_0

BUG: 1518512
Change-Id: I6f753978fd607919efcc60f73c37feaadc4f32ef
Signed-off-by: Mohit Agrawal

features/worm: new config option to manage deletion of Worm files.

2017-11-22T13:48:16+00:00

Add a new configuration option worm-files-deletable to
 file-level Worm in order to control behaviour of Worm files upon deletion.

Steps to Test:
1. Add all the configuration options to a volume to activate file-level-worm
2. Option features.worm-files-deletable is set to 1 by default.
3. Create a new file and wait for the retention time to expire.
4. After retention time expires, do an truncate, rename, unlink, link
   or write to send the file in Worm state.
5. After that do `rm -f filename`.
6. The file is successfully removed.
7. Repeat from step 2 by setting features.worm-files-deletable 0.
   This time deletion should not be successful.

Change-Id: Ibc89861ee296e065330b93a9f9606be5da40af31
BUG: 1508898
Signed-off-by: Vishal Pandey

cluster/ec: Fix op-version for disperse.other-eager-lock

2017-11-16T14:48:45+00:00

The op-version used for the new option was wrong. It has been set
to 3.13.0.

>Change-Id: I88fbd7834e4a8018c8906303e734c251e90be8cf
>BUG: 1502610
>Signed-off-by: Xavier Hernandez 

Change-Id: I88fbd7834e4a8018c8906303e734c251e90be8cf
BUG: 1512460
Signed-off-by: Xavier Hernandez

cluster/ec: create eager-lock option for non-regular files

2017-11-16T14:48:45+00:00

A new option is added to allow independent configuration of eager
locking for regular files and non-regular files.

>Change-Id: I8f80e46d36d8551011132b15c0fac549b7fb1c60
>BUG: 1502610
>Signed-off-by: Xavier Hernandez 

Change-Id: I8f80e46d36d8551011132b15c0fac549b7fb1c60
BUG: 1512460
Signed-off-by: Ashish Pandey

glusterd: display gluster volume status, when quorum type is server

2017-11-14T15:33:00+00:00

Problem: when server-quorum-type is server, after restarting glusterd
in the node which is up, gluster volume status is giving incorrect
information.

Fix: check whether server is blank, before adding other keys into the
dictionary.

Change-Id: I926ebdffab330ccef844f23f6d6556e137914047
BUG: 1511768
Signed-off-by: Sanju Rakonde 
(cherry picked from commit 046c7e3199fca715592762e271e6061ac99b0c4b)