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. 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
