Gluster users - Sep 2017 - GlusterFS as virtual machine storage

2017-09-08 13:21 GMT+02:00 Pavel Szalbot <pavel.szalbot at
gmail.com>:
> Gandalf, isn't possible server hard-crash too much? I mean if reboot
> reliably kills the VM, there is no doubt network crash or poweroff
> will as well.
IIUP, the only way to keep I/O running is to gracefully exiting glusterfsd.
killall should send signal 15 (SIGTERM) to the process, maybe a bug in
signal management
on gluster side? Because kernel is already telling glusterfsd to exit,
though signal 15 but glusterfsd
seems to handle this in a bad way.

a server hard-crash doesn't send any signal. I think this could be
also similiar to SIGKILL (9)
that can't be catched/ignored software side.

In other words: is this a bug in gluster's signal management (if
SIGKILL is working and SIGTERM no, i'll almost sure this is a bug in
signal management),
a engineering bug (relying only on a graceful exit [but even SIGTERM
should be threthed as graceful exit] to preserve I/O on clients) or
something else ?

On Sep 8, 2017 13:36, "Gandalf Corvotempesta" <
gandalf.corvotempesta at gmail.com> wrote:

2017-09-08 13:21 GMT+02:00 Pavel Szalbot <pavel.szalbot at
gmail.com>:
> Gandalf, isn't possible server hard-crash too much? I mean if reboot
> reliably kills the VM, there is no doubt network crash or poweroff
> will as well.
IIUP, the only way to keep I/O running is to gracefully exiting glusterfsd.


No, even killall resp. SIGTERMing glusterfsd ends up with I/O errors on the
client.

I did not test SIGKILL because I suppose if graceful exit is bad, SIGKILL
will be as well. This assumption might be wrong. So I will test it. It
would be interesting to see client to work in case of crash (SIGKILL) and
not in case of graceful exit of glusterfsd.

killall should send signal 15 (SIGTERM) to the process, maybe a bug in
signal management
on gluster side? Because kernel is already telling glusterfsd to exit,
though signal 15 but glusterfsd
seems to handle this in a bad way.

a server hard-crash doesn't send any signal. I think this could be
also similiar to SIGKILL (9)
that can't be catched/ignored software side.


In other words: is this a bug in gluster's signal management (if
SIGKILL is working and SIGTERM no, i'll almost sure this is a bug in
signal management),
a engineering bug (relying only on a graceful exit [but even SIGTERM
should be threthed as graceful exit] to preserve I/O on clients) or
something else ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20170908/85c96fa6/attachment.html>

2017-09-08 13:44 GMT+02:00 Pavel Szalbot <pavel.szalbot at
gmail.com>:
> I did not test SIGKILL because I suppose if graceful exit is bad, SIGKILL
> will be as well. This assumption might be wrong. So I will test it. It
would
> be interesting to see client to work in case of crash (SIGKILL) and not in
> case of graceful exit of glusterfsd.
Exactly. if this happen, probably there is a bug in gluster's signal
management.