glusterfs.git, branch v3.12.5

doc : release-notes for GlusterFS-3.12.5

2018-01-12T13:22:25+00:00

Change-Id: If43009ffe28cf5bcd3ad190d99aac9e412235774
BUG: 1527303
Signed-off-by: Jiffin Tony Thottan

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

2018-01-12T05:43:49+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: 1511301
Signed-off-by: Atin Mukherjee

cluster/dht: Use percentages for space check

2018-01-12T05:37:34+00:00

With heterogenous bricks now being supported in DHT
we could run into issues where files are not migrated
even though there is sufficient space in newly added bricks
which just happen to be considerably smaller than older
bricks. Using percentages instead of absolute available
space for space checks can mitigate that to some extent.

Marking bug-1247563.t as that used to depend on the easier
code to prevent a file from migrating. This will be removed
once we find a way to force a file migration failure.

> Change-Id: I3452520511f304dbf5af86f0632f654a92fcb647
> BUG: 1529440
> Signed-off-by: N Balachandran 

Change-Id: I3452520511f304dbf5af86f0632f654a92fcb647
BUG: 1530455
Signed-off-by: N Balachandran

quota: fixes issue in quota.conf when setting large number of limits

2018-01-10T06:59:18+00:00

Problem: It was not possible to configure more than 7712 quota limits.
This was because a stack buffer of size 131072 was used to read from
quota.conf file. In the new format of quota.conf file each gfid entry
takes 17bytes (16byte gfid + 1 byte type). So, the buf_size was not a
multiple of gfid entry size and as per code this was considered as
corruption.

Solution: make buf size multiple of gfid entry size

Change-Id: Id036225505a47a4f6fa515a572ee7b0c958f30ed
BUG: 1489043
Signed-off-by: Sanoj Unnikrishnan 
(cherry picked from commit 2899a4f125735636fe7cd8db73c0b8a13289df9b)

Revert "mount/fuse: report ESTALE as ENOENT"

2018-01-10T06:56:57+00:00

This reverts commit 26d16b90ec7f8acbe07e56e8fe1baf9c9fa1519e.

Consider rename (index.new, store.idx) and open (store.idx) being
executed in parallel. When we break down operations following sequence
is possible.

* lookup (store.idx) - as part of open(store.idx) returns gfid1 as the
  result.
* rename (index.new, store.idx) changes gfid of store.idx to
  gfid2. Note that gfid2 was the nodeid of index.new. Since rename is
  successful, gfid2 is associated with store.idx.
* open (store.idx) resumes and issues open fop to glusterfs with
  gfid1. open in glusterfs fails as gfid1 doesn't exist and the error
  returned by glusterfs to kernel-fuse is ENOENT.
* kernel passes back the same error to application as a result to
  open.

This error could've been prevented if kernel retries open with
gfid2. Interestingly kernel do retry open when it receives ESTALE
error. Even though failure to find gfid resulted in ESTALE error,
commit 26d16b90ec7f8acb converted that error to ENOENT while sending
an error reply to kernel. This prevented kernel from retrying open
resulting in error.

>Change-Id: I2e752ca60dd8af1b989dd1d29c7b002ee58440b4
>BUG: 1500269
>Signed-off-by: Raghavendra G 

(cherry picked from commit 019a55e708375d2b1e576fcc948a691bcdc5c749)
Change-Id: I2e752ca60dd8af1b989dd1d29c7b002ee58440b4
BUG: 1529088
Signed-off-by: Raghavendra G

cli: Fixed a use_after_free

2018-01-10T06:56:27+00:00

gf_event in cli_cmd_volume_create_cbk was accessing
memory that had already been freed.

> Change-Id: I447c939fa9b31e18819a62c3b356c14cca390787
> BUG: 1530910
> Signed-off-by: N Balachandran 
(cherry picked from commit fa903173540df5b82c295a8f7b24848098e49a41)

Change-Id: I447c939fa9b31e18819a62c3b356c14cca390787
BUG: 1531372
Signed-off-by: N Balachandran

glusterd: Nullify pmap entry for bricks belonging to same port

2018-01-10T06:51:34+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: 1530448
Signed-off-by: Atin Mukherjee

mount/fuse: never fail open(dir) with ENOENT

2018-01-03T10:03:02+00:00

open(dir) being an operation on inode should never fail with
ENOENT. If gfid is not present, the appropriate error is ESTALE. This
will enable kernel to retry open after a revalidate lookup.

>Change-Id: I8d07d2ebb5a0da6c3ea478317442cb42f1797a4b
>BUG: 1500269
>Signed-off-by: Raghavendra G 

(cherry picked from commit fb4b914ce84bc83a5f418719c5ba7c25689a9251)
Change-Id: I8d07d2ebb5a0da6c3ea478317442cb42f1797a4b
BUG: 1529088
Signed-off-by: Raghavendra G

performance/write-behind: fix bug while handling short writes

2018-01-02T09:51:52+00:00

The variabled "fulfilled" in wb_fulfill_short_write is not reset to 0
while handling every member of the list.

This has some interesting consequences:

* If we break from the loop while processing last member of the list
  head->winds, req is reset to head as the list is a circular
  one. However, head is already fulfilled and can potentially be
  freed. So, we end up adding a freed request to wb_inode->todo
  list. This is the RCA for the crash tracked by the bug associated
  with this patch (Note that we saw "holder" which is freed in todo
  list).

* If we break from the loop while processing any of the last but one
  member of the list head->winds, req is set to next member in the
  list, skipping the current request, even though it is not entirely
  synced. This can lead to data corruption.

The fix is very simple and we've to change the code to make sure
"fulfilled" reflects whether the current request is fulfilled or not
and it doesn't carry history of previous requests in the list.

>Change-Id: Ia3d6988175a51c9e08efdb521a7b7938b01f93c8
>BUG: 1528558
>Signed-off-by: Raghavendra G 

(cherry picked from commit 0bc22bef7f3c24663aadfb3548b348aa121e3047)
Change-Id: Ia3d6988175a51c9e08efdb521a7b7938b01f93c8
BUG: 1529095
Signed-off-by: Raghavendra G

rpc-transport/rdma: Add a mutex for the list of RDMA Memory Region(MR) access

2018-01-02T09:50:51+00:00

Problem: gf_rdma_device_t->all_mr is a __gf_rdma_arena_mr(includes MR content)
	 kind of list in the rdma rpc-transport. The rdma rpc-transport will
	 add/delete items to the list when MRs register, deregister, and free.
	 Because gf_rdma_device_t->all_mr is used by different threads
	 and it is not mutex protected, rdma transport maybe access obsolete
	 items in it.

Solution: Add a mutex protection for the gf_rdma_device_t->all_mr.

> Change-Id: I2b7de0f7aa516b90bb6f3c6aae3aadd23b243900
> BUG: 1522651
> Signed-off-by: Yi Wang 

(cherry picked from commit 8483ed87165c1695b513e223549d33d2d63891d9)
Change-Id: I2b7de0f7aa516b90bb6f3c6aae3aadd23b243900
BUG: 1525850
Signed-off-by: Yi Wang