glusterfs.git/xlators/cluster/dht, branch v6dev

build: cleanup xlator link, --no-undefined, libuuid

2018-09-12T14:38:13+00:00

While attempting to build a (pre-)5.0 of glusterfs on Ubuntu
bionic and cosmic, it became apparent that there are some gremlins
hiding in the combination of the xlator export-symbols, the newish
addition of -Wl,--no-undefined, and the new switch to libuuid from
the old contrib/uuid.

Note: even though Fedora 28 (and later) and Ubuntu bionic (and
later) have the same nominal version of libtool, the Fedora version
appears to do a better job of recursing through dependencies to
determine the libraries to link with.

Examination of the build logs showed that despite appearing to work
on Fedora, not all xlators and shared libs were linked with -Wl,
--no-undefined, and -luuid. And in the case of the gnfs xlator, it
was not only not linked with -Wl,--no-undefined but alsos not linked
with -lgfxdr and -lgfrpc.

Added GF_XLATOR_LDFLAGS, similar to GF_XLATOR_DEFAULT_LDFLAGS.
GF_XLATOR_DEFAULT_LDFLAGS is for xlators that export/expose the
default or common set of symbols. GF_XLATOR_LDFLAGS is for those
remaining xlators that export/expose non-default symbols, e.g. dht
and glupy. This removes the need in the future to add things like
$(UUID_LIBS) to every xlator's Makefile.am. Just add it to
GF_XLATOR_LDFLAGS and GF_XLATOR_DEFAULT_LDFLAGS in configure.ac
and you're done.

This patch was tested on Fedora 28 (build, rpmbuild), Fedora
Rawhide/30 (rpmbuild), RHEL8 (rpmbuild), CentOS7 (rpmbuild), Fedora
koji --scratch build for f30/rawhide, and a Launchpad build for
Ubuntu cosmic/18.10.

Change-Id: Ieca104fa5c5d3c094e701c8ca4a73754dd0292b0
updates: bz#1193929
Signed-off-by: Kaleb S. KEITHLEY

Land part 2 of clang-format changes

2018-09-12T12:22:45+00:00

Change-Id: Ia84cc24c8924e6d22d02ac15f611c10e26db99b4
Signed-off-by: Nigel Babu

Land clang-format changes

2018-09-12T11:52:48+00:00

Change-Id: I6f5d8140a06f3c1b2d196849299f8d483028d33b

dht: Use snprintf instead of strncpy

2018-09-12T06:25:31+00:00

The recent changes to use malloc instead
of calloc left the new_name and new_path
non-null terminated. We now use snprintf
instead of strncpy to fix this.

Change-Id: I1a31701ca9447efde38921be0ba2c73cde2e7976
fixes: bz#1626346
Signed-off-by: N Balachandran

cluster/dht: Create a linkto file if required

2018-09-10T14:22:41+00:00

Using the dht_filter_loc_subvol_key to create
files on specific subvols did not create a linkto
file. This can make the file inaccessible as
lookup-optimize is now enabled by default.

Change-Id: I78add5a31887378a479cb9c746b91678876b0dbe
fixes: bz#1626394
Signed-off-by: N Balachandran

cluster/dht: optimize readdir for 1xn vols

2018-09-10T10:49:44+00:00

Skip the hashed subvol check for volumes with
distribute count of 1.

Change-Id: I5703508b54a17c49a217c8a8e09884980705953a
fixes: bz#1608175
Signed-off-by: N Balachandran

xlators/cluster/dht/src/tier-common.c:move to GF_MALLOC() instead of GF_CALLOC() when

2018-09-10T05:15:49+00:00

It doesn't make sense to calloc (allocate and clear) memory
when the code right away fills that memory with data.
It may be optimized by the compiler, or have a microscopic
performance improvement.

Please review carefully, especially for string allocation, with the
terminating NULL string.

Only compile-tested!

Change-Id: I7d38a7d576f6777976fe86e5351a8d95caddbb9c
updates: bz#1193929
Signed-off-by: Yaniv Kaul

cluster/dht: Rework the debug xattr to get hashed subvol

2018-09-07T08:55:32+00:00

The earlier implementation required the file to already exist
when trying to get the hashed subvol. The reworked implementation
allows a user to get the hashed subvol for any filename, whether
it exists or not.

Usage: getfattr -n "dht.file.hashed-subvol." 

Eg:To get the hashed subvol for file-1 inside dir-1

getfattr -n "dht.file.hashed-subvol.file-1" /mnt/gluster/dir1

credit: rgowdapp@redhat.com

Change-Id: Iae20bd5f56d387ef48c1c0a4ffa9f692866bf739
fixes: bz#1624244
Signed-off-by: N Balachandran

xlators/cluster/dht/src/dht-common.c :move to GF_MALLOC() instead of GF_CALLOC() when

2018-09-07T03:41:32+00:00

It doesn't make sense to calloc (allocate and clear) memory
when the code right away fills that memory with data.
It may be optimized by the compiler, or have a microscopic
performance improvement.

Please review carefully, especially for string allocation, with the
terminating NULL string (added another byte to ensure it's there).

Only compile-tested!

Change-Id: Ia5e4f50dfb0c29809c2019fcfd8079507813249e
updates: bz#1193929
Signed-off-by: Yaniv Kaul

multiple xlators: strncpy()->sprintf(), reduce strlen()'s

2018-09-07T03:39:50+00:00

xlators/cluster/afr/src/afr-common.c
xlators/cluster/dht/src/dht-common.c
xlators/cluster/dht/src/dht-rebalance.c
xlators/cluster/stripe/src/stripe-helpers.c

strncpy may not be very efficient for short strings copied into
a large buffer: If the length of src is less than n,
strncpy() writes additional null bytes to dest to ensure
that a total of n bytes are written.

Instead, use snprintf().
Also:
- save the result of strlen() and re-use it when possible.
- move from strlen to SLEN (sizeof() ) for const strings.

Compile-tested only!

Change-Id: Icdf79dd3d9f9ff120e4720ff2b8bd016df575c38
updates: bz#1193929
Signed-off-by: Yaniv Kaul