glusterfs.git/xlators/mgmt/glusterd/src/glusterd-volume-ops.c, branch v6.5

libglusterfs: Move devel headers under glusterfs directory

2018-12-05T21:47:04+00:00

libglusterfs devel package headers are referenced in code using
include semantics for a program, this while it works can be better
especially when dealing with out of tree xlator builds or in
general out of tree devel package usage.

Towards this, the following changes are done,
- moved all devel headers under a glusterfs directory
- Included these headers using system header notation <> in all
code outside of libglusterfs
- Included these headers using own program notation "" within
libglusterfs

This change although big, is just moving around the headers and
making it correct when including these headers from other sources.

This helps us correctly include libglusterfs includes without
namespace conflicts.

Change-Id: Id2a98854e671a7ee5d73be44da5ba1a74252423b
Updates: bz#1193929
Signed-off-by: ShyamsundarR

glusterd: volume-ops calls naked malloc

2018-11-28T04:22:43+00:00

libglusterfs provides wrapper functions MALLOC/__gf_default_malloc,
CALLOC/__gf_default_calloc, and REALLOC/__gf_default_realloc for those
few places outside of mempool.c that need to call malloc/calloc/realloc
directly.

Notable exceptions are "contrib" code, e.g. rbtree and timer-wheel,
and perhaps parsers generated by yacc+lex. But even parsers can be
fixed to at least call the wrappers mentioned above, if not our own
allocators

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

glusterd: allow shared-storage to use bricks under glusterd working directory

2018-11-08T11:53:57+00:00

With commit 44e4db, we are not allowing user to create a volume
using glusterd's working directory as a brick or any sub directory
under glusterd's working directory as a brick.This has broken
shared-storage since the volume "gluster-shared-storage" is
created using the bricks under glusterd's working directory.

With this patch, we let the "gluster-shared-storage" volume
to use bricks under glusterd's working directory.

fixes: bz#1647029
Change-Id: Ifcbcf4576eea12cf46f199dea287b29bd3ec3bfd
Signed-off-by: Sanju Rakonde

glusterd: initialise caps inside #ifdef HAVE_BD_XLATOR block

2018-11-06T06:02:33+00:00

Note: The problem is seen when we disable bd xlator.

Problem: When we create a volume, volume info file is having
caps value as 15 in nodes which hosts bricks for that volume.
Remainig nodes in cluster are not having caps field. When
glusterd is restarted, peers are going into rejected state,
because of this mismacth in configuration files.

Cause: In glusterd_op_create_volume(), we initialise caps
value as 15 in the beginning. Later, we check whether brick
belongs to the same node or not. If brick doesn't belong to
the same node, caps value will be set to 0. If brick belongs
to the same node, we will change the caps value inside

Solution: If brick doesn't belongs to the same node,caps is
set to 0 and if brick belongs to same brick caps value is
changed inside #ifdef HAVE_BD_XLATOR block. So, to have the
consistency across the cluster, we need to initialise caps
value inside #ifdef HAVE_BD_XLATOR block, only when brick
belongs to the same node.

fixes: bz#1645986
Change-Id: I2648f420b21d6e69e7c38b0f4736d41e0f15a7f5
Signed-off-by: Sanju Rakonde

stripe: remove the translator from build and glusterd

2018-10-31T02:24:49+00:00

Based on the proposal to remove few features as they are not
actively maintained [1], removing stripe translator from the
build. Also make sure there are no regression tests involving
stripe translator.

[1] https://lists.gluster.org/pipermail/gluster-users/2018-July/034400.html

Note that this patch aims at removing the translator from build, and
a followup patch is needed to remove the code from repository.

Updates: bz#1364707
Change-Id: I235b305338f138e29e9f30cba65bc0dadbebbbd5
Signed-off-by: Amar Tumballi

glusterd: ensure volinfo->caps is set to correct value.

2018-10-25T12:12:04+00:00

With the commit febf5ed4848, during the volume create op,
we are setting volinfo->caps to 0, only if any of the bricks
belong to the same node and brickinfo->vg[0] is null.
Previously, we used to set volinfo->caps to 0, when
either brick doesn't belong to the same node or brickinfo->vg[0]
is null.

With this patch, we set volinfo->caps to 0, when either brick
doesn't belong to the same node or brickinfo->vg[0] is null.
(as we do earlier without commit febf5ed4848).

fixes: bz#1635820
Change-Id: I00a97415786b775fb088ac45566ad52b402f1a49
Signed-off-by: Sanju Rakonde

glusterd: improve logging for stage_deleted flag

2018-10-23T10:54:47+00:00

Change-Id: I5f0667a47ddd24cb00949c875c19f3d1dbd8d603
fixes: bz#1605077
Signed-off-by: Sanju Rakonde

glusterd: acquire lock to update volinfo structure

2018-09-18T04:09:01+00:00

Problem: With commit cb0339f92, we are using a separate syntask
for restart_bricks. There can be a situation where two threads
are accessing the same volinfo structure at the same time and
updating volinfo structure. This can lead volinfo to have
inconsistent values and assertion failures because of unexpected
values.

Solution: While updating the volinfo structure, acquire a
store_volinfo_lock, and release the lock only when the thread
completed its critical section part.

Fixes: bz#1627610
Signed-off-by: Sanju Rakonde 

Change-Id: I545e4e2368e3285d8f7aa28081ff4448abb72f5d

Land part 2 of clang-format changes

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

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

Some (mgmt) xlators: use dict_{setn|getn|deln|get_int32n|set_int32n|set_strn}

2018-09-09T01:53:59+00:00

In a previous patch (https://review.gluster.org/20769) we've
added the key length to be passed to dict_* funcs, to remove the need
to strlen() it. This patch moves some xlators to use it.

- It also adds dict_get_int32n which was missing.
- It also reduces the size of some key variables.
They were set to 1024b or PATH_MAX, where sometimes 64 bytes were
really enough.

Please review carefully:
1. That I did not reduce some the size of the key variables too much.
2. That I did not mix up some keys.

Compile-tested only!

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