summaryrefslogtreecommitdiffstats
path: root/module/zfs
diff options
context:
space:
mode:
authorJan Sanislo <[email protected]>2015-05-12 13:30:19 -0700
committerBrian Behlendorf <[email protected]>2015-05-14 11:16:52 -0700
commit79065ed5a454d36492a3006fec69f14ddf83a88f (patch)
tree1e3fe5670a1f586153688dee4f568cb70bff92aa /module/zfs
parent7290cd3c4ed19fb3f75b8133db2e36afcdd24beb (diff)
Return -ESTALE to force lookup for missing NFS file handles
There seems to be a annoying problem using NFSv4 to access ZFS file systems under certain circumstances. It's easily reproduced: nfs_client1: mount server:/export /mnt nfs_client1: cd /mnt nfs_client1: echo foo >junk nfs_client1: cat junk foo Now on a different NFSv4 client: nfs_client2: mount server:/export /mnt nfs_client2: cd /mnt nfs_client2: vi junk # Make some changes to /mnt/junk and save # This change the inode associated with /mnt/junk Now back to the original client: nfs_client1: cat junk cat: junk: No such file or directory Admittedly NFSv4 is not advertised as a cluster file system that maintains a completely coherent view of data across multiple nodes. But it does have some mechanisms built in that try to deal with situations like the above. Namely, it employs specialized file handle lookup routines that return ESTALE when a file handle contains a non-existant inode value. The ESTALE return triggers a return full file path lookup from the client to determine if the file has actually gone away or if the cached file handle is no longer valid. ZFS behavior can be brought into line with other file systems (e.g., ext4) by applying the following patch: Signed-off-by: Brian Behlendorf <[email protected]> Closes #3224
Diffstat (limited to 'module/zfs')
-rw-r--r--module/zfs/zpl_export.c15
1 files changed, 14 insertions, 1 deletions
diff --git a/module/zfs/zpl_export.c b/module/zfs/zpl_export.c
index 23d85cad9..4da3a4531 100644
--- a/module/zfs/zpl_export.c
+++ b/module/zfs/zpl_export.c
@@ -102,8 +102,21 @@ zpl_fh_to_dentry(struct super_block *sb, struct fid *fh,
rc = zfs_vget(sb, &ip, fid);
spl_fstrans_unmark(cookie);
- if (rc != 0)
+ if (rc) {
+ /*
+ * If we see ENOENT it might mean that an NFSv4 * client
+ * is using a cached inode value in a file handle and
+ * that the sought after file has had its inode changed
+ * by a third party. So change the error to ESTALE
+ * which will trigger a full lookup by the client and
+ * will find the new filename/inode pair if it still
+ * exists.
+ */
+ if (rc == ENOENT)
+ rc = ESTALE;
+
return (ERR_PTR(-rc));
+ }
ASSERT((ip != NULL) && !IS_ERR(ip));