[Gluster-devel] trusted.glusterfs.version xattr

[Derek Price]

Okay, I think we may be operating with slightly different assumptions 
about the way things are currently happening, so to start off:

1.  I completely agree that processing renames as such would avoid tons 
of unneeded data transfer in the case of renames of large files or 
directories containing them.

2.  I had the understanding due to a comment in another thread that the 
only operations that were going across the AFR wire in the case of a 
rename was a remove and then a create.  If this assumption is wrong, 
somebody please correct me.


Back to our discussion, if "healing a directory listing" includes, as 
you represent, processing of a list of delete, rename, and add 
operations for the directory before its version number is updated, 
guaranteeing that a new but unsynchronized file would have a version # 
of 0 on the client after synchronizing its parent directory, then I 
think your method works.

If, however, the only operations permitted on directory listings is to 
present a new list of the current files and directories (basically adds 
and removes), then your method breaks down because if a directory 
version changes then all children of that directory must be assumed to 
be changed.  For example, in the second FS state shown below, there is 
no way to distinguish which of the three files has changed.  Given:

/:2 a/:2 b/:2 c/:4 /A:1
		   /B:1
		   /C:1

	$ cd /a/b/c
	$ rm C
	$ echo new content >C

renders:

/:2 a/:2 b/:2 c/:6 /A:1
		   /B:1
		   /C:1


My solution solves this last problem (if it, in fact, even exists), 
though not the efficient rename issue (if it, in fact, even exists).  I 
was leaving the transaction journaling issue (basically what you 
represent is already being maintained on a per-directory basis), as a 
future update which would be easier to integrate once the first problem 
was solved.

Regards,

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