Re: 3.17.0+ files disappearing after playing old dos game on nfsroot laptop

[ebiederm@xmission.com (Eric W. Biederman)]

Hans de Bruin <jmdebruin@xmsnet.nl> writes:

>> I expect what needs to happen is to confirm that nfs directory entry
>> revalidation is buggy, and at least for the short term re-add the nfs
>> logic that will avoid dropping a dentry if it is a mount point, or
>> path to a mount point, to avoid the nfs bugs.
>>
>
> ok, I will go in waiting mode.

I dropped the ball on this but it looks like someone else hit the
problem and the following two commits fixed this issue:

Can you confirm that things are working again?

commit fa9233699cc1dc236f4cf42245d13e40966938c5
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Mon Feb 23 18:51:32 2015 -0500

    NFS: Don't require a filehandle to refresh the inode in nfs_prime_dcache()
    
    If the server does not return a valid set of attributes that we can
    use to either create a file or refresh the inode, then there is no
    value in calling nfs_prime_dcache().
    
    However if we're just refreshing the inode using the attributes that
    the server returned, then it shouldn't matter whether or not we have
    a filehandle, as long as we check the fsid+fileid combination.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>

commit 6c441c254eea2354d686be7f5544bcd79fb6a61f
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Sun Feb 22 16:35:36 2015 -0500

    NFS: Don't invalidate a submounted dentry in nfs_prime_dcache()
    
    If we're traversing a directory which contains a submounted filesystem,
    or one that has a referral, the NFS server that is processing the READDIR
    request will often return information for the underlying (mounted-on)
    directory. It may, or may not, also return filehandle information.
    
    If this happens, and the lookup in nfs_prime_dcache() returns the
    dentry for the submounted directory, the filehandle comparison will
    fail, and we call d_invalidate(). Post-commit 8ed936b5671bf
    ("vfs: Lazily remove mounts on unlinked files and directories."), this
    means the entire subtree is unmounted.
    
    The following minimal patch addresses this problem by punting on
    the invalidation if there is a submount.
    
    Kudos to Neil Brown <neilb@suse.de> for having tracked down this
    issue (see link).
    
    Reported-by: Nix <nix@esperi.org.uk>
    Link: http://lkml.kernel.org/r/87iofju9ht.fsf@spindle.srvr.nix
    Cc: stable@vger.kernel.org # 3.18+
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>