glusterfs.git/glusterfsd, branch heal-info

mount.glusterfs: make fcache-keep-open option take a value

2019-08-16T05:35:02+00:00

Fixes: bz#1158130
Change-Id: Ifdeaed7c9fbe85f7ce421f7c89cbe7265e45f77c
Signed-off-by: Amar Tumballi

fuse: Set limit on invalidate queue size

2019-08-14T03:21:03+00:00

If the glusterfs fuse client process is unable to
process the invalidate requests quickly enough, the
number of such requests quickly grows large enough
to use a significant amount of memory.
We are now introducing another option to set an upper
limit on these to prevent runaway memory usage.

Change-Id: Iddfff1ee2de1466223e6717f7abd4b28ed947788
Fixes: bz#1732717
Signed-off-by: N Balachandran

fuse: rate limit reading from fuse device upon receiving EPERM

2019-08-08T06:10:29+00:00

Fixes: bz#1644322
Change-Id: I53e8fa362cd8c7d04fb1c4abb606a9abb642c592
Signed-off-by: Csaba Henk

graph/shd: attach volfile even if ctx->active is NULL

2019-08-05T06:48:20+00:00

While we receive a graph attach request, if ctx->active is
not set we used to fail assuming that the initilization has
not completed yet for the process start.

Since the management connection is established, it will receive
attach request, even when ctx->active is NULL.

Change-Id: Ied4d1ac63e6d4ced4a9405a78e1ce39f81dfd437
fixes: bz#1727256
Signed-off-by: Mohammed Rafi KC

event: rename event_XXX with gf_ prefixed

2019-07-29T04:43:56+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.

Fixes: #699

Change-Id: I38f0200b941bd1cff4bf3066fca2fc1f9a5263aa
Signed-off-by: Xiubo Li

cli: defer create_frame() (and dict creation) to later stages.

2019-07-16T13:34:56+00:00

Where possible, defer create_frame() - whenever possible, after
command line verification, for example.

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

Fix spelling errors

2019-07-14T05:17:46+00:00

Fixes: bz#1728554
Change-Id: I88357aed7c14988a12616035c3738c32c09a8f9a
Signed-off-by: Patrick Matthäi 
Signed-off-by: Aravinda VK

glusterd/svc: update pid of mux volumes from the shd process

2019-07-09T12:19:02+00:00

For a normal volume, we are updating the pid from a the
process while we do a daemonization or at the end of the
init if it is no-daemon mode. Along with updating the pid
we also lock the file, to make sure that the process is
running fine.

With brick mux, we were updating the pidfile from gluterd
after an attach/detach request.

There are two problems with this approach.
1) We are not holding a pidlock for any file other than parent
   process.
2) There is a chance for possible race conditions with attach/detach.
   For example, shd start and a volume stop could race. Let's say
   we are starting an shd and it is attached to a volume.
   While we trying to link the pid file to the running process,
   this would have deleted by the thread that doing a volume stop.

Change-Id: I29a00352102877ce09ea3f376ca52affceb5cf1a
Updates: bz#1722541
Signed-off-by: Mohammed Rafi KC

core: fedora 30 compiler warnings

2019-06-18T10:53:49+00:00

warning: ‘%s’ directive argument is null [-Wformat-overflow=]

Change-Id: I69b8d47f0002c58b00d1cc947fac6f1c64e0b295
updates: bz#1193929
Signed-off-by: SheetalPamecha

multiple files: another attempt to remove includes

2019-06-14T16:50:32+00:00

There are many include statements that are not needed.
A previous more ambitious attempt failed because of *BSD plafrom
(see https://review.gluster.org/#/c/glusterfs/+/21929/ )

Now trying a more conservative reduction.
It does not solve all circular deps that we have, but it
does reduce some of them. There is just too much to handle
reasonably (dht-common.h includes dht-lock.h which includes
dht-common.h ...), but it does reduce the overall number of lines
of include we need to look at in the future to understand and fix
the mess later one.

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