<div dir="ltr"><div>Hello,</div><div><br></div>>It should be enabled alright, but we have noticed some issues of stale locks (<a href="https://github.com/gluster/glusterfs/issues/" target="_blank">https://github.com/gluster/glusterfs/issues/</a> {2198, 2211, 2027}) which could prevent self-heal (or any other I/O that takes a blocking lock) from happening.<div><br></div><div>I have re-enabled cluster.eager-lock.</div><div><br></div><div>>But the problem here is different as you noticed. Thorsten needs to find the actual file (`find -samefile`) corresponding to this gfid and see what is the file size, hard-link count etc.) If it is a zero -byte file, then it should be safe to just delete the file and its hardlink from the brick.<br></div><div><br></div><div>I think, here i need your help :) How i can find the file? I only have the gfid from the out of 'gluster volume heal glusterfs-1-volume info' = <gfid:26c5396c-86ff-408d-9cda-106acd2b0768> on Brick 192.168.1.50:/data/glusterfs.</div><div><br></div><div>Thanks and regards,</div><div>Thorsten</div><div style="font-family:"Hack NF Regular",monospace;white-space:pre"><div><span style="color:rgb(208,208,208);background:rgb(33,33,33)"></span></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am So., 31. Okt. 2021 um 07:35 Uhr schrieb Ravishankar N <<a href="mailto:ravishankar.n@pavilion.io">ravishankar.n@pavilion.io</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 30, 2021 at 10:47 PM Strahil Nikolov <<a href="mailto:hunter86_bg@yahoo.com" target="_blank">hunter86_bg@yahoo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736"><div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736"><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736yMail_cursorElementTracker_1635614000182">Hi,<div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736yMail_cursorElementTracker_1635610951122"><br clear="none"></div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736yMail_cursorElementTracker_1635610951296">based on the output it seems that for some reason the file was deployed locally but not on the 2-nd brick and the arbiter , which for a 'replica 3 arbiter 1' (a.k.a replica 2 arbiter 1) is strange.</div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736yMail_cursorElementTracker_1635614011272"><br clear="none"></div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736yMail_cursorElementTracker_1635614011534">It seems that cluster.eager-lock is enabled as per the virt group: <a id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303linkextractor__1635614155400" href="https://github.com/gluster/glusterfs/blob/devel/extras/group-virt.example" target="_blank">https://github.com/gluster/glusterfs/blob/devel/extras/group-virt.example</a></div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yMail_cursorElementTracker_1635614155427"><br></div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yMail_cursorElementTracker_1635614155635">@Ravi,</div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yMail_cursorElementTracker_1635614164387"><br></div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yMail_cursorElementTracker_1635614164607">do you think that it should not be enabled by default in the virt group ?</div></div></div></div></div></blockquote><div><br></div><div>It should be enabled alright, but we have noticed some issues of stale locks (<a href="https://github.com/gluster/glusterfs/issues/" target="_blank">https://github.com/gluster/glusterfs/issues/</a> {2198, 2211, 2027}) which could prevent self-heal (or any other I/O that takes a blocking lock) from happening. But the problem here is different as you noticed. Thorsten needs to find the actual file (`find -samefile`) corresponding to this gfid and see what is the file size, hard-link count etc.) If it is a zero -byte file, then it should be safe to just delete the file and its hardlink from the brick.</div><div><br></div><div>Regards,</div><div>Ravi</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736"><div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736"><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736yMail_cursorElementTracker_1635614000182"><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yMail_cursorElementTracker_1635614198369"><br></div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yMail_cursorElementTracker_1635614198588">Best Regards,</div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yMail_cursorElementTracker_1635614203092">Strahil Nikolov</div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736yMail_cursorElementTracker_1635611051955"><br clear="none"></div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736yqt53334"><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736yqt16652"><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736yMail_cursorElementTracker_1635611052703"><br clear="none"> <br clear="none"> <blockquote style="margin:0px 0px 20px"> <div style="font-family:Roboto,sans-serif;color:rgb(109,0,246)"> <div>On Sat, Oct 30, 2021 at 16:14, Thorsten Walk</div><div><<a href="mailto:darkiop@gmail.com" target="_blank">darkiop@gmail.com</a>> wrote:</div> </div> <div style="padding:10px 0px 0px 20px;margin:10px 0px 0px;border-left:1px solid rgb(109,0,246)"> <div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Ravi & <span style="color:rgb(0,0,0);white-space:pre-wrap">Strahil</span>, thanks a lot for your answer!<div><br clear="none"><div>The file in the path .glusterfs/26/c5/.. only exists at node1 (=pve01). On node2 (pve02) and the arbiter (freya), the file does not exist:</div><div><br clear="none"></div><div><br clear="none"></div><div><br clear="none"></div><div>┬[14:35:48] [ssh:root@pve01(192.168.1.50): ~ (700)]<br clear="none">╰─># getfattr -d -m. -e hex  /data/glusterfs/.glusterfs/26/c5/26c5396c-86ff-408d-9cda-106acd2b0768<br clear="none">getfattr: Removing leading '/' from absolute path names<br clear="none"># file: data/glusterfs/.glusterfs/26/c5/26c5396c-86ff-408d-9cda-106acd2b0768<br clear="none">trusted.afr.dirty=0x000000000000000000000000<br clear="none">trusted.afr.glusterfs-1-volume-client-1=0x000000010000000100000000<br clear="none">trusted.afr.glusterfs-1-volume-client-2=0x000000010000000100000000<br clear="none">trusted.gfid=0x26c5396c86ff408d9cda106acd2b0768<br clear="none">trusted.glusterfs.mdata=0x01000000000000000000000000617880a3000000003b2f011700000000617880a3000000003b2f011700000000617880a3000000003983a635<br clear="none"><br clear="none">┬[14:36:49] [ssh:root@pve02(192.168.1.51): /data/glusterfs/.glusterfs/26/c5 (700)]<br clear="none">╰─># ll<br clear="none">drwx------ root root   6B 3 days ago   ./<br clear="none">drwx------ root root 8.0K 6 hours ago  ../<br clear="none"><br clear="none">┬[14:36:58] [ssh:root@freya(192.168.1.40): /data/glusterfs/.glusterfs/26/c5 (700)]<br clear="none">╰─># ll<br clear="none">drwx------ root root   6B 3 days ago   ./<br clear="none">drwx------ root root 8.0K 3 hours ago  ../<br clear="none"></div><div><br clear="none"></div><div><br clear="none"></div><div><br clear="none"></div><div>After this, i have disabled the the option you mentioned:</div><div><br clear="none"></div><div>gluster volume set glusterfs-1-volume cluster.eager-lock off<br clear="none"></div><div><br clear="none"></div><div>After that I started another healing process manually. Unfortunately without success.<br clear="none"></div><div><br clear="none"></div><div>@Strahil: For your idea with <a rel="nofollow noopener noreferrer" shape="rect" href="https://docs.gluster.org/en/latest/Troubleshooting/gfid-to-path/" target="_blank">https://docs.gluster.org/en/latest/Troubleshooting/gfid-to-path/</a> i need more time, maybe i can try it tomorrow. I'll be in touch.<br clear="none"></div><div><br clear="none"></div><div>Thanks again and best regards,</div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736yqtfd10144"><div>Thorsten</div></div></div></div></div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736yqtfd56752"><div><br clear="none"></div>
</div></div><div id="gmail-m_-7687957722969662141gmail-m_-6386798838679987303yiv1085954736yqtfd73727">
</div></div></div> </div> </blockquote></div></div></div></div></div></div></div></blockquote></div></div>
</blockquote></div>