Gluster users - May 2016 - Questions about healing

>    Which is the OS reaction to a locked storage?A  It's transparent or
could
>    lead to FS issue?
>    What would happen if healing starts in the middle of a write, for
example
>    when MySQL flush to disks?
In my experience the OS can't notice that, actually. The access to the disk
won't fail,
it'll just wait for the heal to finish before returning : your VM will
freez. When the heal
finishes the access will return correctly and everything will continue as if
nothing happened.
Might depend on the OS though, no idea how windows would react, but for Linux at
least
even hour long heals never caused any problem to the VM, except of course the
fact that
the VM froze and all services on it stopped responding during the heal.

We didn't have sharding at first, and the behaviour is pretty much the same,
but the heals take
forever.

-- 
Kevin Lemonnier
PGP Fingerprint : 89A5 2283 04A0 E6E9 0111
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20160521/c85b9247/attachment.sig>

Il 21 mag 2016 13:49, "Kevin Lemonnier" <lemonnierk at
ulrar.net> ha scritto:
> We didn't have sharding at first, and the behaviour is pretty much the
same, but the heals take
> forever.
That's clear but if you have a cluster of 3, with replica 3, if you loose a
node, you have to heal the whole VM image as shards are not distributed,
as there aren't nodes to distribute to.

All nodes has all shards in my case.

Sharding would be useful in very large cluster where each chunk is
distributed but on small cluster doesn't change too much having a single
file or 500 files on the same server for the same VM image
you still have to heal everything every time you loose a node
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20160521/2413dfc8/attachment.html>