summaryrefslogtreecommitdiffstats
path: root/THANKS
diff options
context:
space:
mode:
authorRaghavendra Bhat <raghavendra@redhat.com>2014-07-17 12:15:54 +0530
committerVijay Bellur <vbellur@redhat.com>2014-09-18 11:02:31 -0700
commit8f4c223c5f7a7a06c3b73dbb94e85d271bd84fb5 (patch)
treeca13431725ccbf3f49b656b37c33169103aa01fe /THANKS
parent82b24d64b9dc89672e6a298648f0e3959b62b1c0 (diff)
snapview-server: get the handle if its absent before doing any fop
* Now that NFS server does inode linking in readdirp, it can resolve the gfid (i.e. find the right inode from its inode table) present in the filehandle sent by the NFS client on which a fop came. So instead of sending the lookup on that entry, it directly sends the fop. But snapview-server does not get the handle for the entries in readdirp (because doing a lookup on each entry via gfapi would be costly. So it waits till a lookup is done on that inode, to get the handle and the fs instance and fill it in the inode context). So when NFS resoves the gfid and directly sends the fop, snapview-server will not be able to perform the fop as the inode contet would not contain the fs instance and the handle. So fops should check for the handle before doing gfapi calls. If the handle and fs instance are not present in the inode context they should get them by doing an explicit lookup on the entry. rebase of the patch http://review.gluster.org/#/c/8324/ Change-Id: I70c9c8edb2e7ddad79cf6ade3e041b9d02241cd1 BUG: 1143961 Reviewed-on: http://review.gluster.org/8768 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Diffstat (limited to 'THANKS')
0 files changed, 0 insertions, 0 deletions