[Gluster-devel] trusted.glusterfs.version xattr
Derek Price
derek at ximbiot.com
Mon May 12 15:03:19 UTC 2008
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
More information about the Gluster-devel
mailing list