On 07/04/2013 07:36 PM, HL wrote: > Hello list, > > I have a 2 node replica clusterfs > > Volume Name: GLVol > Type: Replicate > Volume ID: 2106bc3d-d184-42db-ab6e-e547ff816113 > Status: Started > Number of Bricks: 1 x 2 = 2 > Transport-type: tcp > Bricks: > Brick1: node01:/export/fm_glust > Brick2: node02:/export/fe_glust > Options Reconfigured: > auth.allow: 172.16.35.* > geo-replication.indexing: on > > > After a cable faillure I Have an unstable system, > > gluster volume heal GLVol info split-brain > > Gives about 1000 of these entries .. > > 2013-07-04 16:46:10 <gfid:ce073ea9-a95a-4c5e-b2bd-7db1e26cbad7> > 2013-07-04 16:46:10 <gfid:0d7ff6b2-5ed1-4584-b0e3-9f0c723463b8> > 2013-07-04 16:46:10 /vz_data/mySQLDBS/var/lib/mysql/ib_logfile0 > > I've found a script in the users list on how to deal with > /vz_data/mySQLDBS/var/lib/mysql/ib_logfile0 > that is known path files > > but don't know how to deal with the hex entries ... they seem to me as > orphans ... The hex entries are "gfid"s used by GlusterFS for identifying files and are not orphan objects. A gfid that cannot be resolved to a path by the server immediately, would appear with the hex representation. > > Is ok To delete them ??? Unless the files are in split brain, it is not a good idea to delete them. Letting the self-heal daemon heal these files would be a better approach. Regards, Vijay
