glusterfs.git/rpc, branch v6.6

rpc: Update address family if it is not provide in cmd-line arguments

2019-09-09T06:47:40+00:00

Problem: After enabling transport-type to inet6 and passed ipv6
         transport.socket.bind-address in glusterd.vol clients are
         not started.

Solution: Need to update address-family based on remote-address for
          all gluster client process

> Change-Id: Iaa3588cd87cebc45231bfd675745c1a457dc9b31
> Fixes: bz#1747746
> Credits: Amgad Saleh 
> Signed-off-by: Mohit Agrawal 
> (cherry picked from commit 80b8cfe3f1386606bada97a76a0cad7acdf6b877)

Change-Id: Iaa3588cd87cebc45231bfd675745c1a457dc9b31
Fixes: bz#1739320
Credits: Amgad Saleh 
Signed-off-by: Mohit Agrawal

event: rename event_XXX with gf_ prefixed

2019-08-28T08:34:45+00:00

I hit one crash issue when using the libgfapi.

In the libgfapi it will call glfs_poller() --> event_dispatch()
in file api/src/glfs.c:721, and the event_dispatch() is defined
by libgluster locally, the problem is the name of event_dispatch()
is the extremly the same with the one from libevent package form
the OS.

For example, if a executable program Foo, which will also use and
link the libevent and the libgfapi at the same time, I can hit the
crash, like:

kernel: glfs_glfspoll[68486]: segfault at 1c0 ip 00007fef006fd2b8 sp
00007feeeaffce30 error 4 in libevent-2.0.so.5.1.9[7fef006ed000+46000]

The link for Foo is:
lib_foo_LADD = -levent $(GFAPI_LIBS)
It will crash.

This is because the glfs_poller() is calling the event_dispatch() from
the libevent, not the libglsuter.

The gfapi link info :
GFAPI_LIBS = -lacl -lgfapi -lglusterfs -lgfrpc -lgfxdr -luuid

If I link Foo like:
lib_foo_LADD = $(GFAPI_LIBS) -levent
It will works well without any problem.

And if Foo call one private lib, such as handler_glfs.so, and the
handler_glfs.so will link the GFAPI_LIBS directly, while the Foo won't
and it will dlopen(handler_glfs.so), then the crash will be hit everytime.

The link info will be:
foo_LADD = -levent
libhandler_glfs_LIBADD = $(GFAPI_LIBS)

I can avoid the crash temporarily by linking the GFAPI_LIBS in Foo too like:
foo_LADD = $(GFAPI_LIBS) -levent
libhandler_glfs_LIBADD = $(GFAPI_LIBS)

But this is ugly since the Foo won't use any APIs from the GFAPI_LIBS.

And in some cases when the --as-needed link option is added(on many dists
it is added as default), then the crash is back again, the above workaround
won't work.

Backport of:
> https://review.gluster.org/#/c/glusterfs/+/23110/
> Change-Id: I38f0200b941bd1cff4bf3066fca2fc1f9a5263aa
> Fixes: #699
> Signed-off-by: Xiubo Li 

Change-Id: I38f0200b941bd1cff4bf3066fca2fc1f9a5263aa
updates: bz#1740525
Signed-off-by: Xiubo Li 
(cherry picked from commit 799edc73c3d4f694c365c6a7c27c9ab8eed5f260)

rpc: glusterd start is failed and throwing an error Address already in use

2019-08-19T11:45:19+00:00

Problem: Some of the .t are failed due to bind is throwing
         an error EADDRINUSE

Solution: After killing all gluster processes .t is trying
          to start glusterd but somehow if kernel has not cleaned
          up resources(socket) then glusterd startup is failed due to
          bind system call failure.To avoid the issue retries to call
          bind 10 times to execute system call succesfully

> Change-Id: Ia5fd6b788f7b211c1508c1b7304fc08a32266629
> Fixes: bz#1743020
> Signed-off-by: Mohit Agrawal 
> (cherry picked from commit c370c70f77079339e2cfb7f284f3a2fb13fd2f97)

Change-Id: Ia5fd6b788f7b211c1508c1b7304fc08a32266629
Fixes: bz#1743219
Signed-off-by: Mohit Agrawal

ctime: Set mdata xattr on legacy files

2019-08-06T07:23:43+00:00

Problem:
The files which were created before ctime enabled would not
have "trusted.glusterfs.mdata"(stores time attributes) xattr.
Upon fops which modifies either ctime or mtime, the xattr
gets created with latest ctime, mtime and atime, which is
incorrect. It should update only the corresponding time
attribute and rest from backend

Solution:
Creating xattr with values from brick is not possible as
each brick of replica set would have different times.
So create the xattr upon successful lookup if the xattr
is not created

Note To Reviewers:
The time attributes used to set xattr is got from successful
lookup. Instead of sending the whole iatt over the wire via
setxattr, a structure called mdata_iatt is sent. The mdata_iatt
contains only time attributes.

Backport of:
 > Patch:  https://review.gluster.org/22936
 > Change-Id: I5e535631ddef04195361ae0364336410a2895dd4
 > BUG: 1593542
 > Signed-off-by: Kotresh HR 

Change-Id: I5e535631ddef04195361ae0364336410a2895dd4
updates: bz#1733885
Signed-off-by: Kotresh HR

If bind-address is IPv6 return it successfully

2019-05-29T11:37:24+00:00

>Change-Id: Ibd37b6ea82b781a1a266b95f7596874134f30079
>fixes: bz#1713730
>Signed-off-by: Amgad Saleh 

fixes: bz#1715012
Change-Id: I9a9877b6c32a1ccbd119301a4225808ddaa02de4
Signed-off-by: Hari Gowtham

transport/socket: log shutdown msg occasionally

2019-04-16T13:38:58+00:00

Change-Id: If3fc0884e7e2f45de2d278b98693b7a473220a5e
Signed-off-by: Raghavendra G 
Fixes: bz#1679904
(cherry picked from commit ec1b84300fe267dd12c1e42e7e91905db935f1e2)

rpclib: slow floating point math and libm

2019-04-16T10:48:06+00:00

In release-6 rpc/rpc-lib (libgfrpc) added the function
get_rightmost_set_bit() which calls log2(3), a call that takes
a floating point parameter and returns a floating point.

It's used thusly:
    right_most_unset_bit = get_rightmost_set_bit(...);

(So is it really the right-most unset bit, or the right-most set bit?)

It's unclear to me whether this is in the data path or not. If it is,
it's rather scary to think about integer-to-float and float-to-integer
conversions and slow calls to libm functions in the data path.

gcc and clang have __builtin_ctz() which returns the same result as
get_rightmost_set_bit(), and does it substantially faster. Approx
20M iterations of get_rightmost_set_bit() took ~33sec of wall clock
time on my devel machine, while 20M iterations of __builtin_ctz()
took < 9sec; get_rightmost_set_bit() is 3x slower than __builtin_ctz().

And as a side benefit, we can again eliminate the need to link libgfrpc
with libm.

Change-Id: If9e7e80874577c52223f8125b385fc930de20699
fixes: bz#1692957
Signed-off-by: Kaleb S. KEITHLEY

dict: handle STR_OLD data type in xdr conversions

2019-03-08T14:08:40+00:00

Currently a dict conversion on wire for 3.x protocol happens using
`dict_unserialize()`, which sets the type of data as STR_OLD. But the
new protocol doesn't send it over the wire as its not considered as a
valid format in new processes.

But considering we deal with old and new protocol when we do a rolling
upgrade, it will allow us to get all the information properly with new
protocol.

Credits: Krutika Dhananjay

Fixes: bz#1686364
Change-Id: I165c0021fb195b399790b9cf14a7416ae75ec84f
Signed-off-by: Amar Tumballi

socket: socket event handlers now return void

2019-03-02T11:54:24+00:00

Problem:
Returning any value from socket event handlers to the event sub-system
doesn't make sense since event sub-system cannot handle socket
sub-system errors.

Solution:
Change return type of all socket event handlers to 'void'

mainline:
> Change-Id: I70dc2c57f12b7ea2fae41120f71aa0d7fe0b2b6f
> Fixes: bz#1651246
> Signed-off-by: Milind Changire 
> Reviewed-on: https://review.gluster.org/c/glusterfs/+/22221

Change-Id: I70dc2c57f12b7ea2fae41120f71aa0d7fe0b2b6f
Fixes: bz#1683900
Signed-off-by: Milind Changire 
(cherry picked from commit 776ba851c6ee6c265253d44cf1d6e4e3d4a21772)

Multiple files: reduce work while under lock.

2019-01-29T09:27:22+00:00

Mostly, unlock before logging.
In some cases, moved different code that was not needed
to be under lock (for example, taking time, or malloc'ing)
to be executed before taking the lock.

Note: logging might be slightly less accurate in order, since it may
not be done now under the lock, so order of logs is racy. I think
it's a reasonable compromise.

Compile-tested only!
updates: bz#1193929
Signed-off-by: Yaniv Kaul 

Change-Id: I2438710016afc9f4f62a176ef1a0d3ed793b4f89