Re: [Gluster-devel] self heal problem

[Ed W]

Hi Tejas

>  From the attributes you have shown it seems that you have gone to
> the backend directly, bypassed glusterfs, and hand crafted such a
> situation. The way the code is written, we do not think that we can
> reach the state you have shown in your example.
>
> The remote1 and remote2 attributes show all zeroes which means
> that there were no operations pending on any server.
>    

Just a quick check, but what happens in the case that a file is deleted 
while a replication volume is down?  Are "tombstones" created to track 
the deletions?

It would seem that you could cause the situation that Stephen describes 
as follows:

1) Replication up.  Create a file
2) Bring a replica down
3) Delete the file from the remaining replica
4) Create a new file with the same name as we deleted in 3).  Optionally 
try to trigger things to go wrong by choosing the new file to have older 
ctime, smaller filesize, arbitrary inode, etc
5) Bring replica back up and stat files

In this situation how will gluster handle resolving which version of the 
file to keep?  Our intention is obviously that we want to keep the 
recreated file, however, unless gluster is tracking deletions (dunno - 
is it?) then it's impossible to decide which file to keep simply by 
looking at ctime or other posix attributes of the two files?


Can you comment on glusters algorithm in this situation please?

Ed W