glusterfs.git/xlators/cluster/afr/src, branch release-3.6

afr: launch index heal on local subvols up on a child-up event

2015-09-09T11:53:48+00:00

Backport of http://review.gluster.org/#/c/11912/

Problem: When a replica's child goes down and comes up, the index heal is
triggered only on the child that just came up. This does not serve the intended
purpose as the list of files that need to be healed to this child is actually
captured on the other child of the replica.

Fix: Launch index-heal on all local
children of the replica xlator which just received a child up. Note that
afr_selfheal_childup() eventually calls afr_shd_index_healer() which will not
run the heal on non-local children.

Change-Id: I524fda17c28864758b35679cfb232f81f8374571
BUG: 1256245
Signed-off-by: Ravishankar N 
Reviewed-on: http://review.gluster.org/11994
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: Raghavendra Bhat 
Tested-by: Raghavendra Bhat

cluster/afr: Pick gfid from poststat during fresh lookup for read child calculation

2015-07-17T07:05:36+00:00

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

Change-Id: I03f11af082a0decf4ea084480b67e9e156964c76
BUG: 1235601
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/11408
Reviewed-by: Raghavendra Bhat 
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Raghavendra Bhat

cluster/afr: Do not attempt entry self-heal if the last lookup on entry failed on src

2015-06-19T06:38:01+00:00

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

Test bug-948686.t was causing shd to dump core due to gfid being NULL.
This was due to the volume being stopped while index heal's in progress,
causing afr_selfheal_unlocked_lookup_on() to fail sometimes on the src brick
with ENOTCONN. And when afr_selfheal_newentry_mark() copies the gfid off the
src iatt, it essentially copies null gfid. This was causing the assertion
as part of xattrop in protocol/client to fail.

Change-Id: I81723567af824ce4a9fa37e309eeeab8404ac71e
BUG: 1233036
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/11309
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: Raghavendra Bhat

afr: allow readdir to proceed for directories in split-brain

2015-06-15T16:28:59+00:00

Problem:
afr_read_txn() bails out if read_subvol==-1. This meant that for
directories that were in entry split-brain, FOPS like readdir, access,
stat etc were not allowed.

Fix:
Except for getxattr, all other FOPS are wound on the first up child
of afr.

Change-Id: Iacec8fbb1e75c4d2094baa304f62331c81a6f670
BUG: 1230242
Signed-off-by: Ravishankar N 
Reviewed-on: http://review.gluster.org/10776
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: Anuradha Talur 
(cherry picked from commit 49b428433a03fcf709fdc8c08603b4cf02198e0a)
Signed-off-by: Ravishankar N 
Reviewed-on: http://review.gluster.org/11162
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra Bhat

afr: honour selfheal enable/disable volume set options

2015-06-15T13:18:44+00:00

Backport of  http://review.gluster.org/11012
Note: http://review.gluster.org/9459 is not backported to 3.6 but the change it
makes to afr_get_heal_info() (i.e. handling ret values) is needed for heal info
to work correctly and tests/basic/afr/client-side-heal.t to pass.

--------------------------
afr-v1 had the following volume set options that are used to enable/ disable
self-heals from happening in AFR xlator when loaded in the client graph:
cluster.metadata-self-heal
cluster.data-self-heal
cluster.entry-self-heal

In afr-v2, these 3 heals can happen from the client if there is an inode
refresh. This patch allows such heals to proceed only if the corresponding
volume set options are set to true.
--------------------------

Change-Id: Iebf863758d902fd2f95be320c6791d4e15f634e7
BUG: 1230259
Signed-off-by: Ravishankar N 
Reviewed-on: http://review.gluster.org/11170
Tested-by: Gluster Build System 
Reviewed-by: Anuradha Talur 
Reviewed-by: Raghavendra Bhat

cluster/afr: Treat op_ret >= 0 as success in afr_final_errno()

2015-06-03T12:50:35+00:00

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

Change-Id: I6ca36fee5dc46f2a2afe04f3359c4102f45c3ae0
BUG: 1225745
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/10961
Tested-by: Gluster Build System 
Reviewed-by: Ravishankar N 
Reviewed-by: Raghavendra Bhat

Tests: fix spurious failure in read-subvol-entry.t

2015-05-19T13:15:19+00:00

read-subvol-entry.t tests that if a brick has pending operations,
it is not used for readdir operations. On NetBSD this test exhibits
spurious failures, with the wrong brick being used to perform readdir.

It happens because when afr_replies_interpret() looks at xattr for
pending attributes, it uses alternative bahvior whether it is working
on a directory or another object. The decision is based on inode->ia_type,
which may be IA_INVAL at that time if we come there from:
  afr_replies_interpret.()
  afr_xattrs_are_equal()
  afr_lookup_metadata_heal_chec()
  afr_lookup_entry_heal()
  afr_lookup_cbk()

Using replies[i].poststat.ia_type, which is correctly set, works around
the problem.

Resubmitted as is after rebase.

This is a backport of Id9ccdd8604f79a69db5f1902697f8913acac50ad

BUG: 1138897
Change-Id: I73f5e04dec86e648a28363f417559b0cbf80324d
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/10178
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Raghavendra Bhat

cluster/afr: serialize inode locks

2015-03-25T11:28:33+00:00

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

Problem:
Afr winds inodelk calls without any order, so blocking inodelks
from two different mounts can lead to dead lock when mount1 gets
the lock on brick-1 and blocked on brick-2 where as mount2 gets
lock on brick-2 and blocked on brick-1

Fix:
Serialize the inodelks whether they are blocking inodelks or
non-blocking inodelks.

        Non-blocking locks also need to be serialized.
Otherwise there is a chance that both the mounts which issued same
non-blocking inodelk may endup not acquiring the lock on any-brick.
Ex:
Mount1 and Mount2 request for full length lock on file f1.  Mount1 afr may
acquire the partial lock on brick-1 and may not acquire the lock on brick-2
because Mount2 already got the lock on brick-2, vice versa. Since both the
mounts only got partial locks, afr treats them as failure in gaining the locks
and unwinds with EAGAIN errno.

BUG: 1189023
Change-Id: If5dd502d9d25d12425749a8efcf08a1423b29255
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/9576
Reviewed-by: Krutika Dhananjay 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra Bhat

cluster/afr: Make read child match check in afr optional

2015-03-25T08:58:53+00:00

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

Having this particular check which was introduced by
commit c57c455347a72ebf0085add49ff59aae26c7a70d causes a drop in
performance in readdirp. So the behavior is made configurable with this
patch.

Change-Id: I4a19813cfc786504340264a5a5533a0c43a1d4a4
BUG: 1202673
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/9929
Reviewed-by: Atin Mukherjee 
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: Raghavendra Bhat

afr: remove stale index entries

2015-03-25T08:57:01+00:00

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

Problem:
During pre-op phase, the index xlator
1. Creates the entry inside .glusterfs/indices/xattrop
2. Winds the xattrop fop to posix to mark dirty/pending changelogs.
If the brick crashes after 1, the xattrop entry becomes stale and never
gets removed by shd during subsequent crawls because there is nothing to
heal (changelogs are zero).

Though the stale entry does not get displayed in the output of 'heal info'
command, it nevertheless stays there forever unless a new write tansaction
is performed on the file.

Fix:
During index self-heal if afr xattrs are found to be clean (indicated by
ret value of 2 on a call to afr_shd_selfheal(), send a dummy
post-op with all 0s for the xattr values, which makes the index xlator
to unlink the stale entry.

Change-Id: Iffb171e40490abd8d44df09ccc058b5da67baafe
BUG: 1203081
Signed-off-by: Ravishankar N 
Reviewed-on: http://review.gluster.org/9920
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: Raghavendra Bhat