glusterfs.git/xlators/cluster/afr/src/afr-self-heal.h, branch v3.12.12

afr: heal gfids when file is not present on all bricks

2018-07-11T14:03:47+00:00

Backport of https://review.gluster.org/#/c/20271/ (only change is in .t)

commit 20fa80057eb430fd72b4fa31b9b65598b8ec1265 introduced a regression
wherein if a file is present in only 1 brick of replica *and* doesn't
have a gfid associated with it, it doesn't get healed upon the next
lookup from the client. Fix it.

Change-Id: I7d1111dcb45b1b8b8340a7d02558f05df70aa599
BUG: 1598121
fixes: bz#1598121
Signed-off-by: Ravishankar N 
(cherry picked from commit eb472d82a083883335bc494b87ea175ac43471ff)

cluster/afr: Fail open on split-brain

2018-03-08T06:39:57+00:00

Problem:
Append on a file with split-brain succeeds. Open is intercepted by open-behind,
when write comes on the file, open-behind does open+write. Open succeeds
because afr doesn't fail it. Then write succeeds because write-behind
intercepts it. Flush is also intercepted by write-behind, so the application
never gets to know that the write failed.

Fix:
Fail open on split-brain, so that when open-behind does open+write open fails
which leads to write failure. Application will know about this failure.

Change-Id: I4bff1c747c97bb2925d6987f4ced5f1ce75dbc15
BUG: 1544635
Signed-off-by: Pranith Kumar K 
(cherry picked from commit 786343abca3474ff01aa1017210112d97cbc4843)

afr: heal gfid as a part of entry heal

2017-10-10T05:33:15+00:00

Problem:
If a brick crashes after an entry (file or dir) is created but before
gfid is assigned, the good bricks will have pending entry heal xattrs
but the heal won't complete because afr_selfheal_recreate_entry() tries
to create the entry again and it fails with EEXIST.

Fix:
We could have fixed posx_mknod/mkdir etc to assign the gfid if the file
already exists but the right thing to do seems to be to trigger a lookup
on the bad brick and let it heal the gfid instead of winding an
mknod/mkdir in the first place.

(cherry picked from commit 20fa80057eb430fd72b4fa31b9b65598b8ec1265)
Change-Id: I82f76665a7541f1893ef8d847b78af6466aff1ff
BUG: 1499202
Signed-off-by: Ravishankar N

afr: auto-resolve split-brains for zero-byte files

2017-10-05T12:17:05+00:00

Problems:
As described in BZ 1491670, renaming hardlinks can result in data/mdata
split-brain of the DHT link-to files (T files) without any mismatch of
data and metadata.

As described in BZ 1486063, for a zero-byte file with only dirty bits
set, arbiter brick will likely be chosen as the source brick.

Fix:
For zero byte files in split-brain, pick first brick as
a) data source if file size is zero on all bricks.
b) metadata source if metadata is the same on all bricks

In arbiter case, if file size is zero on all bricks and there are no
pending afr xattrs, pick 1st brick as data source.

(cherry picked from commit 1719cffa911c5287715abfdb991bc8862f0c994e)
Change-Id: I0270a9a2f97c3b21087e280bb890159b43975e04
BUG: 1496317
Signed-off-by: Ravishankar N 
Reported-by: Rahul Hinduja 
Reported-by: Mabi

afr: heal metadata in discover code path

2017-09-11T10:54:39+00:00

Combined backport of https://review.gluster.org/17850 and
https://review.gluster.org/18187

During graph switch, if fuse sends nameless (gfid) lookups, afr takes
the discover code path to serve it. If there are pending metadata heals,
they do not happen unless an inode refresh happens as a part of
discover (which is not guaranteed to happen always).

This patch fixes it by attempting metadata heal as a part of discover,
just like how it is done in lookup code path.

Change-Id: I87c493045b9225741cad173bf3f645848697032e
BUG: 1488168
Signed-off-by: Ravishankar N 
Reviewed-on: https://review.gluster.org/18202
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Karthik U S 
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: jiffin tony Thottan

afr: check validity of afr_reply

2017-09-07T06:46:19+00:00

...in various self-heal code paths.

Originally found by Pranith in __afr_selfheal_name_impunge ()

Also change __afr_selfheal_assign_gfid() to send lookup only on those
bricks that don't have a gfid matching that of the source.


> Reviewed-on: https://review.gluster.org/18065
> Smoke: Gluster Build System 
> CentOS-regression: Gluster Build System 
(cherry picked from commit d594900dbca92c356152be65fce16f77c402117c)

Change-Id: I70a2ccd750a2af92c5fc36e0eefb2b6125404b4a
BUG: 1487319
Signed-off-by: Pranith Kumar K 
Signed-off-by: Ravishankar N 
Reviewed-on: https://review.gluster.org/18173
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System

cluster/afr: GFID split-brain resolution with existing CLI

2017-07-18T15:24:54+00:00

Problem:
Currently there is no way for the admin from CLI to resolve gfid
split-brain based on some policy like choice of the brick, mtime
or size.

Fix:
With the existing CLI options based on size, mtime, and choice of
brick, we do lookup on the parent for the specified file. As
part of the lookup, if we find gfid mismatch, we resolve them
based on the policy and return. If the file is not in gfid split-
brain, then we check for the data and metadata split-brain in the
getxattr code path, and resolve if any.

This will work provided absolute path to the file with the CLI
and not with gfid of the file. Hence the source-brick policy
without any file path will also not resolve the gfid split-brain
since it uses the gfid of the files. But it can resolve any other
type of split-brains and skip the gfid mismatch resolution with
the usual error message.

Reverting the change https://review.gluster.org/17290. This patch
resolves the issue.

Fixes gluster/glusterfs#135

Change-Id: Iaeba6fc32f184a34255d03be87cda02773130a09
BUG: 1459530
Signed-off-by: karthik-us 
Reviewed-on: https://review.gluster.org/17485
Reviewed-by: Ravishankar N 
Reviewed-by: Pranith Kumar Karampuri 
CentOS-regression: Gluster Build System 
Smoke: Gluster Build System

cluster/afr: GFID split brain resolution with favorite-child-policy

2017-04-21T00:38:54+00:00

Problem:
Currently the automatic split brain resolution with favorite child policy
is not resolving the GFID split brains.

Fix:
When there is a GFID split brain and the favorite child policy is set to
size/mtime/ctime/majority, based on the policy decide on the source and
sinks. Delete the entry from the sinks and recreate it from the source.
Mark the appropriate pending attributes and resolve the GFID split brain.
When the heal takes place it will complete the pending heals and reset
the attributes.

Change-Id: Ie30e5373f94ca6f276745d9c3ad662b8acca6946
BUG: 1430719
Signed-off-by: karthik-us 
Reviewed-on: https://review.gluster.org/16878
Smoke: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Pranith Kumar Karampuri 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Ravishankar N 
CentOS-regression: Gluster Build System

syncop: don't wake task in synctask_wake unless really needed

2017-03-28T22:34:48+00:00

Problem:

In EC and AFR, we launch synctasks during self-heal.

(i) These tasks usually stackwind a FOP to all its children and call
synctask_yield() which does a swapcontext to synctask_switchto() and puts the
task in syncenv's waitq by calling __wait(task). This happends as long as the
FOP ckbs from all children haven't been received.

(ii) For each FOP cbk, we call synctask_wake() which again does a swapcontext
to synctask_switchto() which now puts the task in syncenv's runq by calling
__run(task). When the task runs and the conext switches back to the FOP path,
it puts the task in waitq because we haven't heard from all children as
explained in (i).

Thus we are unnecessarily using the swapcontext syscalls to just toggle
the task back and forth between the waitq and runq.

Fix:
Store the stackwind count in new variable 'syncbarrier->waitfor' before
winding the fop. In each cbk when we call synctask_wake(),  perform an actual
wake only if the cbk count == stackwind count.

Change-Id: Id62d3b6ffed5a8c50f8b79267fb34e9470ba5ed5
BUG: 1434274
Signed-off-by: Ravishankar N 
Signed-off-by: Ashish Pandey 
Reviewed-on: https://review.gluster.org/16931
Smoke: Gluster Build System 
Reviewed-by: Niels de Vos 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri

afr: restore atime/mtime for non-regular files

2017-03-06T10:01:43+00:00

AFR restores atime/mtime only as a part of data heal. For non-regular
files (dirs, symlinks, char/block/socket files etc) which do not undergo
data-heal, atime/mtime is not restored.

This patch restores atime/mtime as a part of metadata heal for such
files.

Change-Id: Id8da885fc93fdf65c2f4bae2af3605b146ac1f16
BUG: 1429198
Signed-off-by: Ravishankar N 
Reviewed-on: https://review.gluster.org/16844
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Pranith Kumar Karampuri 
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System