I would prefer the behavior was different to what it is of I/O stopping. The argument I heard for the long 42 second time out was that MTBF on a server was high, and that the client reconnection operation was *costly*. Those were arguments to *not* change the ping timeout value down from 42 seconds. I think it was mentioned that low ping timeout settings could lead to high cpu loads with many clients trying to reconnect if a short timeout was set. This is all hearsay, so the experts should explain it better... ? Diego On Sep 8, 2017 6:50 AM, "Pavel Szalbot" <pavel.szalbot at gmail.com> wrote:> On Fri, Sep 8, 2017 at 12:48 PM, Gandalf Corvotempesta > <gandalf.corvotempesta at gmail.com> wrote: > > I think this should be considered a bug > > If you have a server crash, glusterfsd process obviously doesn't exit > > properly and thus this could least to IO stop ? > > I agree with you completely in this. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170908/da2bef78/attachment.html>
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 killall again... -ps On Fri, Sep 8, 2017 at 12:57 PM, Diego Remolina <dijuremo at gmail.com> wrote:> I would prefer the behavior was different to what it is of I/O stopping. > The argument I heard for the long 42 second time out was that MTBF on a > server was high, and that the client reconnection operation was *costly*. > Those were arguments to *not* change the ping timeout value down from 42 > seconds. I think it was mentioned that low ping timeout settings could lead > to high cpu loads with many clients trying to reconnect if a short timeout > was set. This is all hearsay, so the experts should explain it better... ? > > Diego > > On Sep 8, 2017 6:50 AM, "Pavel Szalbot" <pavel.szalbot at gmail.com> wrote: > >> On Fri, Sep 8, 2017 at 12:48 PM, Gandalf Corvotempesta >> <gandalf.corvotempesta at gmail.com> wrote: >> > I think this should be considered a bug >> > If you have a server crash, glusterfsd process obviously doesn't exit >> > properly and thus this could least to IO stop ? >> >> I agree with you completely in this. >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170908/9cf8102a/attachment.html>
Gandalf Corvotempesta
2017-Sep-08 11:11 UTC
[Gluster-users] GlusterFS as virtual machine storage
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 > killall again... > >Also try to kill the Gluster VM without killing glusterfsd, simulating a server hard-crash . Or try to remove the network interface. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170908/2d815cab/attachment.html>