search for: iiup

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....

So even killall situation eventually kills VM (I/O errors). 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. I am tempted to test this setup on DigitalOcean to eliminate possibility of my hardware/network. But if Diego is able to reproduce the "reboot crash", my doubts of

...< 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....

2017-09-08 13:07 GMT+02:00 Pavel Szalbot <pavel.szalbot at gmail.com>: > OK, so killall seems to be ok after several attempts i.e. iops do not stop > on VM. Reboot caused I/O errors after maybe 20 seconds since issuing the > command. I will check the servers console during reboot to see if the VM > errors appear just after the power cycle and will try to crash the VM after >