path: root/doc
diff options
authorSantosh Kumar Pradhan <>2013-12-17 08:43:50 +0530
committerVijay Bellur <>2013-12-17 03:24:15 -0800
commit329e38d4ab5af1a675b4d5651eda983f8a924418 (patch)
treea5f9df3db31843a6ba229e16593210cfcb3c9542 /doc
parent9031a90613c1cadcab32c418e0e2cc5b14afbba1 (diff)
gNFS: Client cache invalidation with bad fsid
1. Problem: Couple of issues are seen when NFS-ACL is turned ON. i.e. i) NFS directory access is too slow, impacting customer workflows with ACL ii)dbench fails with 100 directories. 2. Root cause: Frequent cache invalidation in the client side when ACL is turned ON with NFS because NFS server getacl() code returns the wrong fsid to the client. 3. This attr-cache invlaidation triggers the frequent LOOKUP ops for each file instead of relying on the readdir or readdirp data. As a result performance gets impacted. 4. In case of dbench workload, the problem is more severe. e.g. Client side rpcdebug output: =========================== Dec 16 10:16:53 santosh-3 kernel: NFS: nfs_update_inode(0:1b/12061953567282551806 ct=2 info=0x7e7f) Dec 16 10:16:53 santosh-3 kernel: NFS: nfs_fhget(0:1b/12061953567282551806 ct=2) Dec 16 10:16:53 santosh-3 kernel: <-- nfs_xdev_get_sb() = -116 [splat] Dec 16 10:16:53 santosh-3 kernel: nfs_do_submount: done Dec 16 10:16:53 santosh-3 kernel: <-- nfs_do_submount() = ffffffffffffff8c Dec 16 10:16:53 santosh-3 kernel: <-- nfs_follow_mountpoint() = ffffffffffffff8c Dec 16 10:16:53 santosh-3 kernel: NFS: dentry_delete(clients/client77, 20008) As per Jeff Layton, This occurs when the client detects that the fsid on a filehandle is different from its parent. At that point, it tries to do a new submount of the new filesystem onto the correct point. It means client got a superblock reference for the new fs and is now looking to set up the root of the mount. It calls nfs_get_root to do that, which basically takes the superblock and a filehandle and returns a dentry. The problem here is that the dentry->d_inode you're getting back looks wrong. It's not a directory as expected -- it's something else. So the client gives up and tosses back an ESTALE. Which clearly says that, In getacl() code while it does the stat() call to get the attrs, it forgets to populate the deviceid or fsid before going ahead and does getxattr(). FIX: 1. Fill the deviceid in iatt. 2. Do bit more clean up for the confusing part of the code. NB: Many many thanks to Niels de Vos and Jeff Layton for their help to debug the issue. Change-Id: I8d3c2a844c9d1761051a883b5ebaeb84062a11c8 BUG: 1043737 Signed-off-by: Santosh Kumar Pradhan <> Reviewed-on: Reviewed-by: Rajesh Joseph <> Reviewed-by: Niels de Vos <> Tested-by: Gluster Build System <> Reviewed-by: Vijay Bellur <>
Diffstat (limited to 'doc')
0 files changed, 0 insertions, 0 deletions