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

[Derek Price]

Martin Fick wrote:
> 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?

I think you are correct.  It might be a useful optimization for quick 
healing to know quickly exactly which directories need to be searched 
for changed files and directories, but it is not strictly necessary and 
could possibly result in the redundant transfer of already up-to-date 
directory listings.

Also, when I first analyzed this, I was working with the underlying 
assumption of synchronous mirrors.  In other words, assuming that any 
given client would be updated to the most recent transaction number 
before it was allowed to process a write request for the next sequential 
transaction.  This would have made for efficient processing of client 
requests like "send me all changes since transaction #1234".

Thinking about it, though, there is no reason this needs to be enforced 
and I think it would, in fact, be an unnecessary limitation.  It would 
be much more efficient if multiple clients could process distinct write 
requests simultaneously and I can't think of a good reason that they 
shouldn't as long as they are not modifying the same directories/files.

In other words, client-a could get permission to process write 
transaction #1234 for file /a/b/c/1 while client-b was processing write 
transaction #1235 for /a/b/c/2 and the file content could be 
synchronized between the mirrors after both transactions completed 
without harm.

Derek
--
Derek R. Price
Solutions Architect
Ximbiot, LLC <http://ximbiot.com>
Get CVS and Subversion Support from Ximbiot!

v: +1 248.835.1260
f: +1 248.246.1176