gluster-devel
[Top][All Lists]
Advanced

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

Re: [Gluster-devel] trusted.glusterfs.version xattr


From: Martin Fick
Subject: Re: [Gluster-devel] trusted.glusterfs.version xattr
Date: Sun, 11 May 2008 14:31:11 -0700 (PDT)

--- Derek Price <address@hidden> wrote:
> Never mind, I thought that, using your algorithm, 
> it was possible to create files in two different
> directories with identical version numbers, then
> move the directories around to swap the paths of
> the files with the same version number, but as I
> tried to come up with an example, I discovered that
> it looks like it isn't possible, starting with an 
> empty file system.

Well, I was wondering the same thing, and although I
haven't come up with an example, I am still tempted to
think that it might be possible and that this solution
is still too complicated.  

So the more I think about it, the more that a globally
unique sequenced id might be more appropriate. 
However, I am not sure why in your suggested scheme
that you are not actually
making the id unique?  When changing a file, 
change the version#, but not the id of the parent
directory.  The sequence # should only be incremented
on creations, not changes.  This way each file/dir has
a unique id (which replaces the timestamp) and a
version #.  All the moving in the world of the
file/dir will never cause two files/dirs to be
confused with each other.  This is very simple and
much more reliable than timestamps.  It seems so
simple that it should be a quick drop in replacement
for the timestamp method with barely any code changes?

The only downfall to this scheme is that one must keep
track of the sequence.  Perhaps this could be
the id of the top level directory (since it cannot
move), or simply add another attribute to the top
level directory to keep track of this.

This scheme seems simpler and more reliable than
either of the others, and it will work well with
extent based quick healing (the method that was
compared to rsync method that was discussed earlier in
another thread), and efficient moves if coded
properly.  If efficient moves are not currently
implemented (they do not seem to be on healing), they
could easily be addressed by the quick healing system
by storing inodes of moved files/dirs so that even on
heals these inodes can be preserved and need not be
recreated!

-Martin



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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]