On Sat, 14 Feb 2015 13:17:00 +0000 Nix <nix@xxxxxxxxxxxxx> wrote: > On 10 Feb 2015, J. Bruce Fields outgrape: > > > It might be interesting to see output from > > > > rpc.debug -m rpc -s cache > > cat /proc/net/rpc/nfsd.export/content > > cat /proc/net/rpc/nfsd.fh/content > > > > especially after the problem manifests. > > So the mount has vanished again. I couldn't make it happen with > nordirplus in the mount options, so that might provide you with a clue. Yup. It does. There is definitely something wrong in nfs_prime_dcache. I cannot quite trace through from cause to effect, but maybe I don't need to. Can you try the following patch and see if that makes the problem disappear? When you perform a READDIRPLUS request on a directory that contains mountpoints, the the Linux NFS server doesn't return a file-handle for those names which are mountpoints (because doing so is a bit tricky). nfs3_decode_dirent notices and decodes as a filehandle with zero length. The "nfs_same_file()" check in nfs_prime_dcache() determines that isn't the same as the filehandle it has, and tries to invalidate it and make a new one. The invalidation should fail (probably does). The creating of a new one ... might succeed. Beyond that, it all gets a bit hazy. Anyway, please try: diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index 9b0c55cb2a2e..a460669dc395 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -541,7 +541,7 @@ int nfs_readdir_page_filler(nfs_readdir_descriptor_t *desc, struct nfs_entry *en count++; - if (desc->plus != 0) + if (desc->plus != 0 && entry->fh.size) nfs_prime_dcache(desc->file->f_path.dentry, entry); status = nfs_readdir_add_to_array(entry, page); which you might have to apply by hand. Thanks, NeilBrown
Attachment:
pgpNbWkkYoEFJ.pgp
Description: OpenPGP digital signature
