Re: trusted.glusterfs.version xattr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



--- Martin Fick <mogulguy@xxxxxxxxx> wrote:
>   Original creation process and versioning:
> 
>   /
>  v1
>   /dir1/
>  v2   v1
>   /dir1/dir2/
>  v2   v2   v1
>   /dir1/dir2/file
>  v2   v2   v2  v1
> 
> Mirror goes off-line with version #s of dir2 and
> file as: v2/v1.
> 
> -> file deleted
> 
>   /dir1/dir2/
>  v2   v2   v3
> 
> -> dir2 deleted
> 
>   /dir1/
>  v2   v3
> 
> -> dir2 recreated
> 
>   /dir1/dir2/
>  v2   v4   v1
> 
> -> file recreated
> 
>   /dir1/dir2/file
>  v2   v4   v2   v1
...
> However, if we were looking at the versions all the 
> way to the root, when the mirror went off-line we 
> would have had: /v2/v2/v2/v1 and now we have: 
> /v2/v4/v2/v1.  There is a chance that we are 
> talking about different files now.  Of course, the
> problem I see now is that the files could in fact 
> have been the same even though the version number is
> different with this scheme!  Since the only version
> # that is different is that of dir1 (v4), this could
> have been caused by simply adding two new files to 
> that directory!  

Hmm, I think that my logic may have been flawed here
and that the scheme would actually work (as long as 
you go to the root).  The mismatch above would only
exist if in fact the file had been recreated!  If the
file had not been recreated, its version # would still
be /v2/v2/v2/v1 and even though if you were to
recalculate it now it would yield /v2/v4/v2/v1.  But
we are not recalculating it, we are trying to see
if the files on two subnodes were created at the 
same time, and thus the version history should have
been the same right?

This assumption only holds if the parent directories
all the way to root are healed before a file is
created/modified though.  I am, not sure that it
currently does with AFR? Does it?  

If the parent directories (all the way up) are not
healed, then a version mismatch could be created 
when a file is modified and its version is updated.  
In this case, despite the version mismatches, the 
files are in fact the same.  It does not seem like 
it would be too difficult to force the parent
directories to heal before writing to the file. 
Unless, a directory heal causes all changed file 
data (or just new files+data?) in those directories 
to heal, that could be a long delay.  Thoughts?  I 
must admit, I am having a hard time following all 
these constraints. :)  ... If this works, no 
useless resyncing because we thought that files 
have changed as I previously surmised.

Cheers,

-Martin



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux