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
