[Gluster-devel] afr's return "struct stat" scheme
LI Daobing
lidaobing at kingsoft.com
Tue Jan 8 03:08:41 UTC 2008
Hello,
just a little review on the afr return "struct stat" scheme
there are 18 functions[1] in xlator_fops which return a struct stat*
in cbk. in 1.3.7 afr implement 16 of them(except fchmod and fchown,
which return ENOSYS), and in TLA, all of them is implemented.
most of them adopt a scheme to return a stable struct stat* when no
child is out of work. It pick the successful returned value which is
first appeared in the conf file. fstat and 1.3.7 readv is a little
difference with others, these two functions do not send the op to all
children, but only the first succesful child. So it's also stable. And
in TLA, some funtion is changed to serial call (for example, mknod),
and the returned struct stat is also come from the first succesful
child, so it's also stable.
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.
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?
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.
Any suggestion?
Thanks.
[1]
1. lookup
2. stat
3. fstat
4. chmod
5. fchmod
6. chown
7. fchown
8. truncate
9. ftruncate
10. utimens
11. mknod
12. mkdir
13. symlink
14. rename
15. link
16. create
17. readv
18. writev
--
Best Regards,
LI Daobing
More information about the Gluster-devel
mailing list