Re: trusted.glusterfs.version xattr

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

 



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




[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