That does the trick. And now I recall reading that in the archives as well. I notice that the only explanation of self-heal in the wiki docs is in the unify translator page: ( http://www.gluster.org/docs/index.php/Understanding_Unify_Translator). Any suggestions for a good place to start an explanation of passive self-heal in afr? thanks again, august! On 9/10/07, Matt Paine <matt@xxxxxxxxxxxxxxxx> wrote: > > Hi August > > > > Take a simple 2 machine afr mirror for example (spec file below). I > > have a brick on machine A doing afr to the brick on machine B and vice > > versa. If one of the bricks goes down and I create a file on the > > remaining one, is there any way to have healing done with the other > > brick comes back up? > > At the moment the self heal functionality is passive. I.e. you need to > do an open on the file to kick in self-heal. I believe the dev team are > working on active self heal (like what you are describing). > > > You could try running this short script to find all your files and open > them, which should self-heal every file if neccesary > > find /mnt/glusterfs/ -type -f -exec head -c 1 {} \; > > Or something along those lines anyway :) > > > > In my testing, I don't see any evidence of self-heal in afr even > > though several folks have it in their spec files. When I bring the > > other machine back online, files that were create while it was down > > are never created on the mirror brick. > > > > Can someone with a more intimate knowledge of the code comment on this > > ? thanks... > > > > > As I said - simply open that file and self-heal will kick in. As far as > I am aware this is the way it works on both afr and unify xlators at the > moment - and also I believe the devs are working on an automated way to > do self heal if its a requirement. > > > > > Matt. > > > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel >
