On 1 March 2017 at 17:15, Gandalf Corvotempesta <
gandalf.corvotempe...@gmail.com> wrote:
> Why not automate this or adding a command that does heal automatically
> when corruption is found?
>
> Nobody wants corrupted files on the storage, why you don't heal
> automatically?
>
Probably because
Why not automate this or adding a command that does heal automatically when
corruption is found?
Nobody wants corrupted files on the storage, why you don't heal
automatically?
Something like
gluster volume bitrot *VOLNAME* heal start
Il 1 mar 2017 7:32 AM, "Sweta Anandpara"
Bitrot has a scrub process which detects the corrupted file. Once
detected, it is the prerogative of the user to follow the sequence of
steps [1] to trigger a heal. Having said that, client access to that
file is not impacted as it continues to serve data from the good copy.
Steps remain the
There is a patch on this [1]. Reviews from wider audience will be helpful,
before we merge the patch.
https://review.gluster.org/#/c/16731/
regards,
Raghavendra
On Wed, Jan 11, 2017 at 4:19 PM, Milind Changire
wrote:
> +gluster-users
>
> Milind
>
>
> On 01/11/2017 03:21
On 1 March 2017 at 09:20, Ernie Dunbar wrote:
> Every node in the Gluster array has their RAID array configured as RAID5,
> so I'd like to improve the performance on each node by changing that to
> RAID0 instead.
Hi Ernie, sorry saw your question before and meant to
In a replica 3, what happens in case of bit-rot detection on a file ?
Is gluster smart enough to detect this and automatically heal the
corrupted files from other replicas ?
What if in case of replica 2 ? How do know know which is right,
server1 or server2, without a quorum ?
What if the
Hi,
We have a Gluster volume hosting VMs for ESXi exported via Ganesha.
Im getting the following messages in ganesha-gfapi.log and ganesha.log
=
[2017-02-28 07:44:55.194621] E [MSGID: 109040]
[dht-helper.c:1198:dht_migration_complete_check_task] 0-vmware2-dht:
: failed to lookup the