On 11/16/2013 04:24 PM, Diego Lendoiro wrote: > Hello everyone; > > First I would like to congratulate all the gluster community for such a > project. I have been using gluster for a while and I am very happy with > it :-) > > I am facing the following situation in a gluster distributed volume > deploy that currently uses gluster 3.4.0 and native gluster clients. > > For some reason, which I don't know yet, configuration files > (/var/lib/glusterd/) have been damaged so the volumes config is lost but > the data remains intact. You could have possibly re-generated the configuration files by performing a volume set option: #gluster volume set <volname> network.ping-timeout 42 would have created the configuration files back. > > I have been advised in #gluster that I can recreate the volumes without > losing the data. I have followed this procedure: > > 0.Create a backup of each brick. > 1.Umounting the partitions that contain the gluster volumes. > 2.Create the distributed volume again in the same mount point that it > was previously. > 3.Mount the data. > 4.Start the volume. > > Step 4 was outputing an error regarding the volume-id so I followed the > instructions from Joe Julian's website: > http://joejulian.name/blog/glusterfs-path-or-a-prefix-of-it-is-already-part-of-a-volume/ > > After a while I managed to start the volume and mount the data in my > clients but I have some inconsistencies like some files are missing in > some of the bricks. Are files missing in the bricks or are they missing when seen from native gluster clients? If files are not being seen from the native clients, it is more likely that a glusterfsd server is not online. Does gluster volume status report that all processes are online for this volume? Regards, Vijay