search for: spongy

...A?????? N/A Y?????? 3667 Task Status of Volume brick1 ------------------------------------------------------------------------------ There are no active volume tasks When we return the c1g node, we do see a "pause" in the VMs as the shards heal. By pause meaning a terminal session gets spongy, but that passes pretty quickly. Also are your VMs mounted in libvirt with caching? We always use cache='none' so we can migrate around easily. Finally, you seem to be using oVirt/RHEV. Is it possible that your platform is triggering a protective response on the VMs (by suspending). -...

...t; Task Status of Volume brick1 > ------------------------------------------------------------------------------ > There are no active volume tasks > > When we return the c1g node, we do see a "pause" in the VMs as the shards > heal. By pause meaning a terminal session gets spongy, but that passes > pretty quickly. Hmm, do you see any errors in VM's dmesg? Or any other reasons for "sponginess"? > Also are your VMs mounted in libvirt with caching? We always use > cache='none' so we can migrate around easily. No cache, virtio: <disk ty...

...lume brick1 >> ------------------------------------------------------------------------------ >> There are no active volume tasks >> >> When we return the c1g node, we do see a "pause" in the VMs as the shards >> heal. By pause meaning a terminal session gets spongy, but that passes >> pretty quickly. > > Hmm, do you see any errors in VM's dmesg? Or any other reasons for "sponginess"? > >> Also are your VMs mounted in libvirt with caching? We always use >> cache='none' so we can migrate around easily. > >...

2017-09-08 14:11 GMT+02:00 Pavel Szalbot <pavel.szalbot at gmail.com>: > Gandalf, SIGKILL (killall -9 glusterfsd) did not stop I/O after few > minutes. SIGTERM on the other hand causes crash, but this time it is > not read-only remount, but around 10 IOPS tops and 2 IOPS on average. > -ps So, seems to be reliable to server crashes but not to server shutdown :)

Hello, How good is :SPA 841 form SIPURA. Thanks Varun

Gandalf, SIGKILL (killall -9 glusterfsd) did not stop I/O after few minutes. SIGTERM on the other hand causes crash, but this time it is not read-only remount, but around 10 IOPS tops and 2 IOPS on average. -ps On Fri, Sep 8, 2017 at 1:56 PM, Diego Remolina <dijuremo at gmail.com> wrote: > I currently only have a Windows 2012 R2 server VM in testing on top of > the gluster storage,