If the backend GFID file only exists in Master 1, then it looks like stale GFID 
exists due to some failure. Run getfattr on that file to see if it shows any 
file path in gfid2path xattr. Please share the output of the following command.



getfattr -d -m . ./d5/3f/d53fad8f-84e9-4b24-9eb0-ccbcbdc4baa8



Meanwhile move this file to a backup location and see if Geo-rep succeeds.



We can introspect the details about the GFID 
d53fad8f-84e9-4b24-9eb0-ccbcbdc4baa8. Please share the matching changelog files 
from 



grep -R "d53fad8f-84e9-4b24-9eb0-ccbcbdc4baa8" .glusterfs/changelogs/*


--
Aravinda


Kadalu Technologies





---- On Fri, 09 Feb 2024 16:23:45 +0530 Anant Saraswat 
<anant.saras...@techblue.co.uk> wrote ---



Hi mailto:hunter86...@yahoo.com,



As mentioned earlier this gfid has "1" in 2nd column of 'ls' command output, 
which means
 this gfid doesn't have any other hardlink.



[root@master1 .glusterfs]# ls -l ./d5/3f/d53fad8f-84e9-4b24-9eb0-ccbcbdc4baa8
 -rw-r--r-- 1 root root 174592 Jan 22 15:06 
./d5/3f/d53fad8f-84e9-4b24-9eb0-ccbcbdc4baa8


Still, I have searched in "/opt/tier1data2019/brick/.glusterfs" and there is 
only one file comes with samefile
 option, which is gfid itself, please check the following output.



[root@master1 .glusterfs]# find . -samefile 
./d5/3f/d53fad8f-84e9-4b24-9eb0-ccbcbdc4baa8
 ./d5/3f/d53fad8f-84e9-4b24-9eb0-ccbcbdc4baa8




You have mentioned the other option to link it somewhere on the real filesystem 
and then sync it to the other
 brick. Here, what do you mean by the real filesystem? Do you want me to link 
this GFID with an existing file on the brick? Or do you want the GFID to be 
linked with some temporary file, say, on "/tmp/test_file," and then sync 
"/tmp/test_file" and 
"/opt/tier1data2019/brick/.glusterfs/d5/3f/d53fad8f-84e9-4b24-9eb0-ccbcbdc4baa8"
 to master2 and master3 nodes?



Many thanks,

Anant


From: Strahil Nikolov <mailto:hunter86...@yahoo.com>
 Sent: 09 February 2024 5:28 AM
 To: Anant Saraswat <mailto:anant.saras...@techblue.co.uk>; Diego Zuccato 
<mailto:diego.zucc...@unibo.it>; mailto:gluster-users@gluster.org 
<mailto:gluster-users@gluster.org>; Aravinda Vishwanathapura 
<mailto:aravi...@kadalu.tech>
 Subject: Re: [Gluster-users] __Geo-replication status is getting Faulty after 
few seconds  


EXTERNAL: Do not click links or open attachments if you do not recognize the 
sender.

The other option around (if indeed is the only in .glusterfs) is to have it 
link somewhere on the real filesystem structure and then sync it to the other 
bricks.

If georep works again - just remove it from the fuse and check if it will get 
deleted or not.



Best Regards,

Strahil Nikolov
 

On Fri, Feb 9, 2024 at 7:25, Strahil Nikolov

<mailto:hunter86...@yahoo.com> wrote:

It's a hard link, so use find's '-samefile' option to see if it's the last one 
or not.



If you really want to delete it, have a backup and then delete both the gfid 
and any other hard links.



Best Regards,

Strahil Nikolov
 








DISCLAIMER: This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error, please
 notify the sender. This message contains confidential information and is 
intended only for the individual named. If you are not the named addressee, you 
should not disseminate, distribute or copy this email. Please notify the sender 
immediately by email if
 you have received this email by mistake and delete this email from your 
system. 
 
 If you are not the intended recipient, you are notified that disclosing, 
copying, distributing or taking any action in reliance on the contents of this 
information is strictly prohibited. Thanks for your cooperation.
________



Community Meeting Calendar:

Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: https://meet.google.com/cpu-eiue-hvk
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

Reply via email to