Hmmm, strange, I went through all my bricks with every time the same result: -bash: cd: /mnt/public/brick1/.glusterfs/31/38/3138d605-25ec-4aa9-9069-5db2e4202db4: No such file or directory The directory /mnt/public/brick1/.glusterfs/31/38 does exist, and indeed there’s a symlink in there but not one with the referenced gfid. Any further suggestions? If I can get rid of the message it’s ok. Thanks in advance. Kind regards Davy > On 21 Sep 2015, at 11:59, Ravishankar N <ravishankar@xxxxxxxxxx> wrote: > > > > On 09/21/2015 03:09 PM, Davy Croonen wrote: >> Ravi >> >> Thanks for your quick reply. >> >> I didn’t solve the split-brain on the file because I don’t know to which directory this gfid is referencing (due to the implementation of our application we have multiple directories containing the same files). > > <gfid:3138d605-25ec-4aa9-9069-5db2e4202db4>/Doc1_LOUJA.htm - Is in split-brain. > > Directories are symlinked inside the .glusterfs folder on the bricks. You can `cd /mnt/public/brick1/.glusterfs/31/38/3138d605-25ec-4aa9-9069-5db2e4202db4` and get to the file 'Doc1_LOUJA.htm' and then resolve the split-brain. > > HTH, > Ravi >> >> Running the command “getfattr -m . -d -e hex <directory>” against every directory which could be the one didn’t show up the mentioned gfid. But there was one result that didn’t fit the picture, see results below: >> >> root@gfs01a-dcg:/mnt/public/brick1/provil/Timetable# getfattr -m . -d -e hex h9cnBmEx6j26sgidVKLaZhAqh >> # file: h9cnBmEx6j26sgidVKLaZhAqh >> trusted.afr.dirty=0x000000000000000000000000 >> trusted.afr.public-client-0=0x000000000000000000000000 >> trusted.afr.public-client-1=0x000000000000000000000000 >> trusted.gfid=0xb560c2463f5b476fa95d318f6bb91356 >> trusted.glusterfs.dht=0x00000001000000007ffe51f8ffffffff >> >> root@gfs01a-dcg:/mnt/public/brick1/provil/Timetable# getfattr -m . -d -e hex h9cnBmEx6j26sgidVKLaZhAqh1442579382189160 >> # file: h9cnBmEx6j26sgidVKLaZhAqh1442579382189160 >> trusted.afr.dirty=0x000000000000000000000000 >> trusted.afr.public-client-0=0x000000000000000000000000 >> trusted.afr.public-client-1=0x000000000000000000000000 >> trusted.gfid=0x0367b477d5ea4b62b4da174b33622457 >> >> On the other hand there is also the possibility that the directory doesn’t even exist anymore because every night there are running some cleanup scripts. >> >> By the way we are running gluster version 3.6.4. >> >> Davy >> >>> On 21 Sep 2015, at 11:16, Ravishankar N <ravishankar@xxxxxxxxxx> wrote: >>> >>> >>> >>> On 09/21/2015 02:32 PM, Davy Croonen wrote: >>>> Hi all >>>> >>>> For, at the moment a unknown reason, the command "gluster volume heal public info” shows a lot of the following entries: >>>> >>>> <gfid:3138d605-25ec-4aa9-9069-5db2e4202db4>/Doc1_LOUJA.htm - Is in split-brain. >>>> >>>> The part after the / differs but the gfid is always the same, I suppose this gfid is referring to a directory. >>> Correct, it is the parent directory of the file in question. >>>> Now considering the data this isn’t an issue the files can be or are already deleted, but is there a way to clear these split-brain entries? >>> Did you actually resolve the split-brain on the file ? If you do that, then the entry must disappear from the output of the heal info command. >>>> The command for restarting the self heal daemon “gluster v start public force”, didn’t solve the problem. Any other suggestions? >>> What version of gluster are you running? >>> >>> -Ravi >>>> Thanks in advance. >>>> >>>> >>>> Kind regards >>>> Davy >>>> _______________________________________________ >>>> 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
