[Gluster-devel] trusted.glusterfs.version xattr

[Krishna Srinivas]

On Mon, May 12, 2008 at 3:01 AM, Martin Fick <mogulguy at yahoo.com> wrote:
> --- Derek Price <derek at ximbiot.com> 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.

Martin,
Avati came up with a similar idea during our discussion here.
Having a unique-transaction-id instead of "create time"
will fix things. I think there are no pit falls, have to see if it
covers all possible cases.

Thanks
Krishna

>
> 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
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>