Re: trusted.glusterfs.version xattr

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

 



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




[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