[Gluster-devel] trusted.glusterfs.version xattr

[Derek Price]

Derek Price wrote:
> /: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

Incidentally, I think my solution may be slightly more efficient, even 
in the case where add/delete/rename journaling is already happening. 
Consider the above case.  When the client requests /a/b/c/A:2/2/2/4/1 
and /a/b/c/C:2/2/2/4/1 from the server, the server would need to either 
process its journal for transactions 5 & 6 to see that file C was going 
to change before it sent something like this across the wire:

	/a/b/c:2/2/2/6 JOURNALENTRIES
	/a/b/c/A:2/2/2/6/1 UPTODATE
	/a/b/c/C:2/2/2/6/1 FILECONTENT

or just send the directory update (first line), wait for the client to 
process the journal and rerequest the files (adding an extra network 
turn-around), then send something like the second two lines above.

Using the global transaction ID as version numbers would enable the 
server to see instantly that the client needed new content for file C 
and skip updating the directory:

/:7 a/:7 b/:7 c/:7 /A:5
                    /B:6
                    /C:7

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

renders:

/:9 a/:9 b/:9 c/:9 /A:5
                    /B:6
                    /C:9



Allowing a client request for /a/b/c/A:5 and /a/b/c/C:7 and an instant 
response from the server, generated by ignoring directories and simply 
looking at the version #'s on the files themselves, like:

	/a/b/c/A:5 UPTODATE
	/a/b/c/C:9 FILECONTENT

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