glusterfs.git, branch v6.10

Adding release notes for release-6.10

2020-08-05T11:03:33+00:00

Fixes: #1417

Change-Id: I1e4140b2c3a38961c66ca98c843b577a5530f029
Signed-off-by: Rinku Kothiya

rpc: Cleanup SSL specific data at the time of freeing rpc object

2020-07-13T06:13:47+00:00

Problem: At the time of cleanup rpc object ssl specific data
         is not freeing so it has become a leak.

Solution: To avoid the leak cleanup ssl specific data at the
          time of cleanup rpc object

> Credits: l17zhou 
> Fixes: bz#1768407
> Change-Id: I37f598673ae2d7a33c75f39eb8843ccc6dffaaf0
> (cherry picked from commit 54ed71dba174385ab0d8fa415e09262f6250430c)

Change-Id: I37f598673ae2d7a33c75f39eb8843ccc6dffaaf0
Fixes: #1016
Signed-off-by: Mohit Agrawal

socket/ssl: fix crl handling

2020-07-10T04:36:02+00:00

Problem:
Just setting the path to the CRL directory in socket_init() wasn't working.

Solution:
Need to use special API to retrieve and set X509_VERIFY_PARAM and set
the CRL checking flags explicitly.
Also, setting the CRL checking flags is a big pain, since the connection
is declared as failed if any CRL isn't found in the designated file or
directory. A comment has been added to the code appropriately.

> Change-Id: I8a8ed2ddaf4b5eb974387d2f7b1a85c1ca39fe79
> fixes: bz#1687326
> Signed-off-by: Milind Changire 
> (Cherry pick from commit 06fa261207f0f0625c52fa977b96e5875e9a91e0)
> (Reviewed on upstream link https://review.gluster.org/#/c/glusterfs/+/22334)

Change-Id: I8a8ed2ddaf4b5eb974387d2f7b1a85c1ca39fe79
Fixes: #1362
Signed-off-by: Mohit Agrawal

locks/fencing: Address hang while lock preemption

2020-07-08T09:49:17+00:00

The fop_wind_count can go negative when fencing is enabled
on unwind path of the IO leading to hang.

Also changed code so that fop_wind_count needs to be maintained only
till fencing is enabled on the file.

> updates: bz#1717824
> Change-Id: Icd04b42bc16cd3d50eaa581ee57233910194f480
> signed-off-by: Susant Palai 
(backport of https://review.gluster.org/#/c/glusterfs/+/23088/)

fixes: bz#1740494
Change-Id: Icd04b42bc16cd3d50eaa581ee57233910194f480
Signed-off-by: Susant Palai

features/shard: Fix crash during shards cleanup in error cases

2020-07-08T02:31:44+00:00

A crash is seen during a reattempt to clean up shards in background
upon remount. And this happens even on remount (which means a remount
is no workaround for the crash).

In such a situation, the in-memory base inode object will not be
existent (new process, non-existent base shard).
So local->resolver_base_inode will be NULL.

In the event of an error (in this case, of space running out), the
process would crash at the time of logging the error in the following line -

        gf_msg(this->name, GF_LOG_ERROR, local->op_errno, SHARD_MSG_FOP_FAILED,
               "failed to delete shards of %s",
               uuid_utoa(local->resolver_base_inode->gfid));

Fixed that by using local->base_gfid as the source of gfid when
local->resolver_base_inode is NULL.

Change-Id: I0b49f2b58becd0d8874b3d4b14ff8d92a89d02d5
Fixes: #1127
Signed-off-by: Krutika Dhananjay 
(cherry picked from commit cc43ac8651de9aa508b01cb259b43c02d89b2afc)

cli: duplicate defns of cli_default_conn_timeout and cli_ten_minutes_timeout

2020-07-08T02:23:11+00:00

Winter is coming. So is gcc-10.

Compiling with gcc-10-20191219 snapshot reveals dupe defns of
cli_default_conn_timeout and cli_ten_minutes_timeout in
.../cli/src/cli.[ch] due to missing extern decl.

There are many changes coming in gcc-10 described in
https://gcc.gnu.org/gcc-10/changes.html

compiling cli.c with gcc-9 we see:
   ...
        .quad   .LC88
        .comm   cli_ten_minutes_timeout,4,4
        .comm   cli_default_conn_timeout,4,4
        .text
   .Letext0:
   ...

and with gcc-10:
   ...
        .quad   .LC88
        .globl  cli_ten_minutes_timeout
        .bss
        .align 4
        .type   cli_ten_minutes_timeout, @object
        .size   cli_ten_minutes_timeout, 4
   cli_ten_minutes_timeout:
        .zero   4
        .globl  cli_default_conn_timeout
        .align 4
        .type   cli_default_conn_timeout, @object
        .size   cli_default_conn_timeout, 4
   cli_default_conn_timeout:
        .zero   4
        .text
   .Letext0:
   ...

which is reflected in the .o file as (gcc-9):
...
0000000000000004 C cli_ten_minutes_timeout
0000000000000004 C cli_default_conn_timeout
...

and (gcc-10):
...
0000000000000020 B cli_ten_minutes_timeout
0000000000000024 B cli_default_conn_timeout
...

See nm(1) and ld(1) for a description C (common) and B (BSS) and how
they are treated by the linker.

Note: there is still a small chance that gcc-10 will land in Fedora-32,
despite 31 Dec. 2019 having been the deadline for that to happen.

Change-Id: I54ea485736a4910254eeb21222ad263721cdef3c
Fixes: #1349
Signed-off-by: Kaleb S. KEITHLEY 
(cherry picked from commit f66bd85af09397300ad434655fc68861f48c2e3c)

afr: event gen changes

2020-07-08T02:19:40+00:00

The general idea of the changes is to prevent resetting event generation
to zero in the inode ctx, since event gen is something that should
follow 'causal order'.

Change #1:
For a read txn, in inode refresh cbk, if event_generation is
found zero, we are failing the read fop. This is not needed
because change in event gen is only a marker for the next inode refresh to
happen and should not be taken into account by the current read txn.

Change #2:
The event gen being zero above can happen if there is a racing lookup,
which resets even get (in afr_lookup_done) if there are non zero afr
xattrs. The resetting is done only to trigger an inode refresh and a
possible client side heal on the next lookup. That can be acheived by
setting the need_refresh flag in the inode ctx. So replaced all
occurences of resetting even gen to zero with a call to
afr_inode_need_refresh_set().

Change #3:
In both lookup and discover path, we are doing an inode refresh which is
not required since all 3 essentially do the same thing- update the inode
ctx with the good/bad copies from the brick replies. Inode refresh also
triggers background heals, but I think it is okay to do it when we call
refresh during the read and write txns and not in the lookup path.

The .ts which relied on inode refresh in lookup path to trigger heals are
now changed to do read txn so that inode refresh and the heal happens.

Change-Id: Iebf39a9be6ffd7ffd6e4046c96b0fa78ade6c5ec
Fixes: #1179
Signed-off-by: Ravishankar N 
Reported-by: Erik Jacobson 
(cherry picked from commit f0fcd909ad4535b60c9208d4804ebe6afe421a09)

cluster/afr: Prioritize ENOSPC over other errors

2020-07-08T01:29:06+00:00

Problem:
In a replicate/arbiter volume if file creations or writes fails on
quorum number of bricks and on one brick it is due to ENOSPC and
on other brick it fails for a different reason, it may fail with
errors other than ENOSPC in some cases.

Fix:
Prioritize ENOSPC over other lesser priority errors and do not set
op_errno in posix_gfid_set if op_ret is 0 to avoid receiving any
error_no which can be misinterpreted by __afr_dir_write_finalize().

Also removing the function afr_has_arbiter_fop_cbk_quorum() which
might consider a successful reply form a single brick as quorum
success in some cases, whereas we always need fop to be successful
on quorum number of bricks in arbiter configuration.

Change-Id: I106e267f8b9451f681022f1cccb410d9bc824c08
Fixes: #1254
Signed-off-by: karthik-us 
(cherry picked from commit fa63b45ca5edf172b1b89b28b5db3c5129cc57b6)

afr: more quorum checks in lookup and new entry marking

2020-07-08T01:26:32+00:00

Problem: See github issue for details.

Fix:
-In lookup if the entry exists in 2 out of 3 bricks, don't fail the
lookup with ENOENT just because there is an entrylk on the parent.
Consider quorum before deciding.

-If entry FOP does not succeed on quorum no. of bricks, do not perform
new entry mark.

Fixes: #1303
Change-Id: I56df8c89ad53b29fa450c7930a7b7ccec9f4a6c5
Signed-off-by: Ravishankar N 
(cherry picked from commit c4a6748f25d2c1ab3ebcf89952278ebf94c8d371)

fuse: degrade logging of write failure to fuse device

2020-07-08T01:24:15+00:00

Problem:

FUSE uses failures of communicating with /dev/fuse with various
errnos to indicate in-kernel conditions to userspace. Some of these
shouldn't be handled as an application error. Also the standard
POSIX errno description should not be shown as they are misleading
in this context.

Solution:

When writing to the fuse device, the caller of the respective
convenience routine can mask those errnos which don't qualify to
be an error for the application in that context, so then those
shall be reported at DEBUG level.

The possible non-standard errnos are reported with their
POSIX name instead of their description to avoid confusion.
(Eg. for ENOENT we don't log "no such file or directory",
we log indeed literal "ENOENT".)

Change-Id: I510158843e4b1d482bdc496c2e97b1860dc1ba93
>updates: bz#1193929
updates: #1000
Signed-off-by: Csaba Henk 
(cherry picked from commit 1166df1920dd9b2bd5fce53ab49d27117db40238)