glusterfs.git/xlators, branch v5.2

afr: thin-arbiter 2 domain locking and in-memory state

2018-12-12T14:26:42+00:00

2 domain locking + xattrop for write-txn failures:
--------------------------------------------------
- A post-op wound on TA takes AFR_TA_DOM_NOTIFY range lock and
AFR_TA_DOM_MODIFY full lock, does xattrop on TA and releases
AFR_TA_DOM_MODIFY lock and stores in-memory which brick is bad.

- All further write txn failures are handled based on this in-memory
value without querying the TA.

- When shd heals the files, it does so by requesting full lock on
AFR_TA_DOM_NOTIFY domain. Client uses this as a cue (via upcall),
releases AFR_TA_DOM_NOTIFY range lock and invalidates its in-memory
notion of which brick is bad. The next write txn failure is wound on TA
to again update the in-memory state.

- Any incomplete write txns before the AFR_TA_DOM_NOTIFY upcall release
request is got is completed before the lock is released.

- Any write txns got after the release request are maintained in a ta_waitq.

- After the release is complete, the ta_waitq elements are spliced to a
separate queue which is then processed one by one.

- For fops that come in parallel when the in-memory bad brick is still
unknown, only one is wound to TA on wire. The other ones are maintained
in a ta_onwireq which is then processed after we get the response from
TA.

Change-Id: I32c7b61a61776663601ab0040e2f0767eca1fd64
updates: bz#1648205
Signed-off-by: Ravishankar N 
Signed-off-by: Ashish Pandey

features/bitrot: compare the signature with proper length

2018-12-12T12:59:18+00:00

* The scrubber was comparing the checksum of the file that it
  calculated (by reading the file) with the on disk signature
  (stored via xattr) wrongly. It was using strlen to calculate
  the signature, while the actual length of the signature is
  given by the brick. Just use the actual length that the brick
  provides instead of trying to calculate the signature length via
  strlen API.

* In posix, gfid2path was using the same string that contains the
  list of all the xattrs of file to save the value of the gfid2path
  xattr as well. This causes confusion when gfid2path xattr is queried
  by scrubber for getting the actual path of a corrupted file. Use
  separate string to fetch the value of the xattr instead of the string
  that contains the list of xattrs.

Backport of:
 > Patch: https://review.gluster.org/21752/
 > BUG: 1654805
 > Change-Id: I2d664ab524d2b312233476cb35863dde3122e9a9
(cherry picked from commit f77fb6d568616592ab25501c402c140d15235ca9)
 
Change-Id: I2d664ab524d2b312233476cb35863dde3122e9a9
fixes: bz#1654370
Signed-off-by: Raghavendra Bhat

afr: assign gfid during name heal when no 'source' is present.

2018-12-12T12:57:59+00:00

Problem:
If parent dir is in split-brain or has dirty xattrs set, and the file
has gfid missing on one of the bricks, then name heal won't assign the
gfid.

Fix:
Use the brick we select the gfid from as the 'source'.

Note: Problem was found while trying to debug a split-brain issue on
Cynthia Zhou's setup.

fixes: bz#1655545
Change-Id: Id088d4f0fb017aa35122de426654194e581ed742
Reported-by: Cynthia Zhou 
Signed-off-by: Ravishankar N 
(cherry picked from commit 4d58730c0cd6ab5db39aec8a15276f7bd3371b04)

leases: Do not conflict with internal fops

2018-12-12T12:54:48+00:00

Internal fops (with frame->root->pid < 0) are used to heal
or move data and maintains data integrity. That is they do not
modify client data which holds the lease. Hence no need to recall
Lease for such fops.

Note: Like for locks, we would need rebalance and self-heal
daemon process to heal lease state as well.

Change-Id: I8988693fef8d00e17c19dcc842e2238f9eb5ab48
updates: bz#1651323
Signed-off-by: Soumya Koduri 
(cherry picked from commit 080aa5b9e9d998552e23f7c33aed3afb0ca93c34)

lease: Treat unlk request as noop if lease not found

2018-12-12T12:53:10+00:00

When the glusterfs server recalls the lease, it expects
client to flush data and unlock the lease. If not it sets
a timer (starting from the time it sends RECALL request) and post
timeout, it revokes it.

Here we could have a race where in client did send UNLK
lease request but because of network delay it may have reached
after server revokes it. To handle such situations, treat
such requests as noop and return sucesss.

Change-Id: I166402d10273f4f115ff04030ecbc14676a01663
updates: bz#1651323
Signed-off-by: Soumya Koduri 
(cherry picked from commit c2e758b54d8a3f778e3e63db0000bb8b63de9b25)

leases: Fix incorrect inode_ref/unrefs

2018-11-29T15:34:57+00:00

From testing & code-reading, found couple of places where
we incorrectly unref the inode resulting in use_after_free
crash or ref leaks. This patch addresses couple of them.

a) When we try to grant the very first lease for a inode,
inode_ref is taken in __add_lease. This ref should be active
till all the leases granted to that inode are released (i.e,
till lease_cnt > 0). In addition even after lease_cnt becomes '0',
the inode should be active till all the blocked fops are resumed.

Hence release this ref, after resuming all those fops. To avoid
granting new leases while resuming those fops, defined a new boolean
(blocked_fops_resuming) to flag it in the lease_ctx.

b) 'new_lease_inode' which creates new lease_inode_entry and
takes ref on inode, is used while adding that entry to
client_list and recall_list.

Use its counter function '__destroy_lease_inode' which does unref
while removing those entries from those lists.

c) inode ref is also taken when added to timer->data. Unref the same
after processing timer->data.

Change-Id: Ie77c78ff4a971e0d9a66178597fb34faf39205fb
updates: bz#1651323
Signed-off-by: Soumya Koduri 
(cherry picked from commit b7aec05aa965202ab73120acf0da4c32fe0cf16c)

afr: open_ftruncate_cbk should read fd from local->cont.open struct

2018-11-29T15:34:44+00:00

afr_open stores the fd as part of its local->cont.open struct
but when it calls ftruncate (if open flags contain O_TRUNC), the
corresponding cbk function (afr_ open_ftruncate_cbk) is
incorrectly referencing uninitialized local->fd. This patch fixes
the same.

Change-Id: Icbdedbd1b8cfea11d8f41b6e5c4cb4b44d989aba
updates: bz#1651322
Signed-off-by: Soumya Koduri 
(cherry picked from commit fda594875c4cdb2a22e27aa13f5c66bee032ccb5)

cluster/afr: Use 2 domain locking in SHD for thin-arbiter

2018-11-29T15:33:37+00:00

With this change when SHD starts the index crawl it requests
all the clients to release the AFR_TA_DOM_NOTIFY lock so that
clients will know the in memory state is no more valid and
any new operations needs to query the thin-arbiter if required.

When SHD completes healing all the files without any failure, it
will again take the AFR_TA_DOM_NOTIFY lock and gets the xattrs on
TA to see whether there are any new failures happened by that time.
If there are new failures marked on TA, SHD will start the crawl
immediately to heal those failures as well. If there are no new
failures, then SHD will take the AFR_TA_DOM_MODIFY lock and unsets
the xattrs on TA, so that both the data bricks will be considered
as good there after.

>Change-Id: I037b89a0823648f314580ba0716d877bd5ddb1f1
>fixes: bz#1579788
>Signed-off-by: karthik-us 
(cherry picked from commit 5784a00f997212d34bd52b2303e20c097240d91c)

Change-Id: I037b89a0823648f314580ba0716d877bd5ddb1f1
fixes: bz#1648205

cluster/ec: prevent infinite loop in self-heal full

2018-11-29T15:31:39+00:00

There was a problem in commit 7f81067 that caused infinite loop when
full heal was triggered.

The previous commit was made to prevent self-heal to go idle after a
replace brick operation. One of the changes consisted on setting a
flag to force an immediate scan of the dirty directory if a heal on
a directory succeeded (assuming it could have generated newer entries).

However that change was causing an issue with a full self-heal, since
every time an already healed directory was checked and it returned
suceessfully, it was also setting the flag, forcing self-heal to start
over again.

This patch fixes this issue by only setting the flag if the heal is not
full. It's assumed that a full self-heal will already traverse all
entries automatically, so there's no need to force a new scan later.

>Change-Id: Id12dbfc04e622b18183e796cc6cc87ccc30a6d55
>fixes: bz#1636631
>Signed-off-by: Xavi Hernandez 
(cherry picked from commit 7150c51ad75ccba22045a35fc31e5037612d1ad4)

Change-Id: Id12dbfc04e622b18183e796cc6cc87ccc30a6d55
fixes: bz#1651525
Signed-off-by: Xavi Hernandez

cluster/ec: Change log level to DEBUG for lookup combine

2018-11-14T15:36:52+00:00

As lookup is not a locked fop, we can not trust the
data received in this to be same.

Changing the log level to DEBUG in case lookup finds any
difference.

(cherry picked from commit 9be6bf3d90e3783b3ba559c93d41b933f8d53f03)

Change-Id: I39499c44688a2455c7c6c69a798762d045d21b39
updates: bz#1644622
Signed-off-by: Ashish Pandey