On Jan 9, 2008 7:14 PM, LI Daobing <lidaobing@xxxxxxxxxxxx> wrote: > On Jan 9, 2008 7:37 PM, Krishna Srinivas <krishna@xxxxxxxxxxxxx> wrote: > > Hello, > > > > > > but ftruncate, writev, lookup and TLA-version does not return a stable > > > struct stat, ftruncate and writev pick the return value from the last > > > successful returned child . and lookup pick the child with the largest > > > mtime. the TLA-version readv return the struct stat from the rchild. > > > > i have to check in your findings of writev and ftruncate, thanks. did that > > fix your vi editing problem? > No. :) > > And I found that the unify also does not return a stable mtime, so I > need setup another test env without unify to check whether this patch > works. > > > Regarding lookup, it returns stat of the entry with the greatest mtime > > but retaining the inode number of the first successful child. Ideally we > > should return stat of the entry based on xattrs createtime and version > > and not mtime (this change will soon go in) > > I don't think so. First if xattrs createtime and version are not same, > you should trigger a selfheal first. After self heal, the xattrs > createtime and version will be same with each other. So I don't think > this scheme will work. No, selfheal happens only when open is done, so when lookup is done selfheal would not have happened (we have plans to give config option of whether selfheal should be done in lookup or open) Doing selfheal on open works well in case the user decides to rm the file before opening so that unnecessary selfheal is avoided. > > And I think lookup should use same scheme with other 17 functions to > return a stable mtime. > > > > > > > > > > > Bug: > > > when you use vim on a glusterfs file system (with afr and the children > > > of afr direct to different machine). Sometimes you will get a warning: > > > The file has been changed since reading it!!! I have submitted this > > > bug at https://savannah.nongnu.org/bugs/?21945, but the patch provided > > > by me only concern the writev and ftruncate functions, so it still > > > can't fix this bug. I will provide a improved patch later. > > > > > > But is there a good excuse to let lookup return the stat with a largest mtime? > > > > It is just that the copy with the latest mtime will have the latest > > correct attributes. > > How ever as i said we should really look at the xattrs createtime & > > version to decide > > on the latest stat. > > same with above. > > > > > > > > > And > > > If you use read-volume option in afr, I suggest you putting the > > > `read-volume' volume at the first place in the sub-volumes. > > > > I did not understand this, can you explain? > > afr_readv_cbk also return a struct stat* (I haven't check whether this > returned stat will update stat in fuse level). If we want keep the > returned struct stat* as stable as possible, we should keep the > retuned stat from the same sub-volume. So It's better to read from the > sub-volume which return the struct stat* in other functions. > > Thanks. > > -- > > Best Regards, > LI Daobing > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel >
