[Gluster-devel] afr's return "struct stat" scheme

[LI Daobing]

On Jan 9, 2008 7:37 PM, Krishna Srinivas <krishna at zresearch.com> 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