Re: Self healing does not see files to heal

[Ravishankar N <ravishankar@xxxxxxxxxx>]

On 08/17/2016 10:40 AM, Krutika Dhananjay wrote:

Good question.

Any attempt from a client to access /.shard or its contents from the mount point will be met with an EPERM (Operation not permitted). We do not expose .shard on the mount point.

Just to be clear, I was referring to the shard xlator accessing the participant shard by sending a named lookup when we access the file (say 'cat /mount/file > /dev/null`) from the mount.
I removed a shard and its hard-link from one of the bricks of a 2 way replica, unmounted the client, stopped and started the volume and did read the file from a fresh mount. For some reason (I need to debug why), a reverse heal seems to be happening where both bricks of the 2-replica volume end up with zero byte file for the shard in question.
-Ravi

-Krutika

On Wed, Aug 17, 2016 at 10:04 AM, Ravishankar N <ravishankar@xxxxxxxxxx> wrote:

On 08/17/2016 07:25 AM, Lindsay Mathieson wrote:

On 17 August 2016 at 11:24, Ravishankar N <ravishankar@xxxxxxxxxx> wrote:

The right way to heal the corrupted files as of now is to access them from
the mount-point like you did after removing the hard-links. The list of
files that are corrupted can be obtained with the scrub status command.

Hows that work with sharding where you can't see the shards from the
mount point?

If sharding xlator does a named lookup of the shard in question as and when it is accessed, AFR can heal it. But I'm not sure if that is the case though. Let me check and get back.
-Ravi

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users