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
<ravishan...@redhat.com <mailto:ravishan...@redhat.com>> wrote:
On 08/17/2016 07:25 AM, Lindsay Mathieson wrote:
On 17 August 2016 at 11:24, Ravishankar N
<ravishan...@redhat.com <mailto:ravishan...@redhat.com>> 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@gluster.org <mailto:Gluster-users@gluster.org>
http://www.gluster.org/mailman/listinfo/gluster-users
<http://www.gluster.org/mailman/listinfo/gluster-users>
_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-users
