diff options
author | Jan Sanislo <[email protected]> | 2015-05-12 13:30:19 -0700 |
---|---|---|
committer | Brian Behlendorf <[email protected]> | 2015-05-14 11:16:52 -0700 |
commit | 79065ed5a454d36492a3006fec69f14ddf83a88f (patch) | |
tree | 1e3fe5670a1f586153688dee4f568cb70bff92aa /module/zfs | |
parent | 7290cd3c4ed19fb3f75b8133db2e36afcdd24beb (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.c | 15 |
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)); |