[Gluster-devel] Re: Unexpected behaviour when self-healing

[Daniel Wirtz]

Hello Krishna,

On Thu, May 29, 2008 at 9:53 AM, Krishna Srinivas <krishna at zresearch.com>
wrote:

> As you guessed it unify+AFR already does the functionality you are talking
> about in the "balance" translator.

It cannot be achived in the same manner afaik. If you have some files that
shall be distributed 3 times, some 5 times and others just 1 time, the
configuration will become extremely complex and as far as I know it is also
not possible to let glusterfs chose random nodes for storage, e.g. you have
to manually define the nodes where a "3 times" file will be stored etc.. If
there already is a way to achive this randomly, I would be very happy to
know. If not, take my immaginary balance translater as a feature wish :)

> Lets fix the problem of selfheal you faced when you started this thread,
> is it still valid?

Yes it is. When I started this thread, I were using server side AFR to
replicate two datastorages and two namespaces each. Then I used unify on the
AFRed ds and ns, also serverside. I did not find a way to get this basic
setup working as expected (see the detailed description earlier in this
thread). In the underlying export directories there were also some files
with a timestamp of 1970-01-01 created (replicated copies created by AFR?).

In the meantime I decided to swtich to clientside AFR without a namespace
(as provided by unify). Self-Healing basically works this way as expected
but I also see some files being 1970-01-01ed in the underlying export
directories. Let's say I create a file on Server A, it will be replicated to
Server B with a timestamp of "0". However, it will show up with the correct
timestamp in glusterfs mounts as long as there is one copy in the cluster
with the real timestamp. The problem is, if first Server A crashes and later
Server B, the timestamp will be incorrect also in mounted directories until
the file is touched again. When it is touched, the timestamp is corrected on
both nodes, so it seems that the incorrect timestamp only is set on
creation, not on update. I am using Debian Etch with GlusterFS 1.3.9 on
ext3. Both servers are correctly synchronized.

regards
Daniel