Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 29 Feb 2020 09:11:17 -0800
From:   Phil Oester <kernel@linuxace.com>
To:     Olga Kornievskaia <aglo@umich.edu>
Cc:     linux-nfs@vger.kernel.org
Subject: Re: NFS "fileid changed" errors since 5.3
Message-ID: <20200229171117.GA66753@home.linuxace.com>
References: <20200227023914.GC33510@home.linuxace.com>
 <CAN-5tyEN-3x-vEUXvch6Xv_e2x0us2XwVcZGpC4-0vsL2f9n7w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAN-5tyEN-3x-vEUXvch6Xv_e2x0us2XwVcZGpC4-0vsL2f9n7w@mail.gmail.com>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On Fri, Feb 28, 2020 at 11:29:24AM -0500, Olga Kornievskaia wrote:
> On Wed, Feb 26, 2020 at 9:39 PM Phil Oester <kernel@linuxace.com> wrote:
> >
> > When running on 5.3 or 5.4 kernels and mounting a Netapp filer via NFSv3
> > and accessing the .snapshot directory, "fileid changed" errors appear
> > in dmesg.  Reverting these 2 patches solves the issue:
> >
> > eb3d8f42231aec: NFS: Fix inode fileid checks in attribute revalidation code
> > 7e10cc25bfa0dd: NFS: Don't refresh attributes with mounted-on-file information
> >
> > Various condition checks changed around printing that error in these
> > commits, but I'm unclear whether the errors are spurious or something
> > I should actually be concerned about.  Thoughts?
> >
> 
> Hi Phil,
> 
> Can you provide a bit more about your Netapp setup? Netapp version and
> any kind of setup you have enabled (like are you using qtrees? have
> you toggles v4-fsid-change?) ,. I can't reproduce this on my setup.

Hi Olga,

The Netapp is running Ontap 9.6P2.  This particular volume has no qtrees.
Also I have not toggled v4-fsid-change, but as noted I am mounting the
volume via NFSv3, so this should not be related.

Some additional information I've found: the fileid changes also occur on
a 4.19.106 kernel, but on that kernel there is no error printed.  So this
again leads me to believe that this is a common occurrence, but the conditionals
which changed in 5.3+ kernels only now are causing it to be printed.

From 4.19.106:

[root@hq1-kvm9 (stg) poester] # ls -i /var/lib/libvirt/images/.snapshot | grep daily.2020-02-2._0010    
70566464 daily.2020-02-28_0010
70573019 daily.2020-02-29_0010
[root@hq1-kvm9 (stg) poester] # ls -i /var/lib/libvirt/images/.snapshot | grep daily.2020-02-2._0010    
70566464 daily.2020-02-28_0010
70573019 daily.2020-02-29_0010
[root@hq1-kvm9 (stg) poester] # find /var/lib/libvirt/images/.snapshot > /dev/null
[root@hq1-kvm9 (stg) poester] # ls -i /var/lib/libvirt/images/.snapshot | grep daily.2020-02-2._0010    
70566464 daily.2020-02-28_0010
70572864 daily.2020-02-29_0010 <=== Note fileid changed here

Nothing showed up in dmesg on that kernel, but in the 5.4.latest stable kernel
that would cause the "fileid changed" error to print.

Thanks,
Phil