<div dir="ltr"><div>Good question.<br><br>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.<br><br></div>-Krutika<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 17, 2016 at 10:04 AM, Ravishankar N <span dir="ltr"><<a href="mailto:ravishankar@redhat.com" target="_blank">ravishankar@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/17/2016 07:25 AM, Lindsay Mathieson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 17 August 2016 at 11:24, Ravishankar N <<a href="mailto:ravishankar@redhat.com" target="_blank">ravishankar@redhat.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The right way to heal the corrupted files as of now is to access them from<br>
the mount-point like you did after removing the hard-links. The list of<br>
files that are corrupted can be obtained with the scrub status command.<br>
</blockquote>
<br>
Hows that work with sharding where you can't see the shards from the<br>
mount point?<br>
<br>
</blockquote></span>
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.<br>
-Ravi<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<wbr>_________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://www.gluster.org/mailman<wbr>/listinfo/gluster-users</a><br>
</div></div></blockquote></div><br></div>