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