On Sep 8, 2017 13:36, "Gandalf Corvotempesta" < gandalf.corvotempe...@gmail.com> wrote:
2017-09-08 13:21 GMT+02:00 Pavel Szalbot <pavel.szal...@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 ?
_______________________________________________ Gluster-users mailing list Gluster-users@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-users