On Fri, Jul 07, 2017 at 12:13:36PM -0400, Jeff Layton wrote:

On Fri, 2017-07-07 at 11:51 -0400, Theodore Ts'o wrote:

quoted

On Fri, Jul 07, 2017 at 06:51:37AM -0400, Jeff Layton wrote:

quoted

Right. That's the case today if we don't remove support for old
filehandles. If we were to remove them, the clients would get back
-ESTALE there if they tried to use the old 2.2-style fh's that they saw
before the upgrade.

The main takeaway here is that NFS filehandle lifetime is really only
bounded by the boot time of the oldest clients.

Well, and how long an NFS server is still up.  So one could construct
a use case where a (hypothetical) system administrator had a RHEL 7.0
system with a 2.2.16-22 kernel, and they try to update it to a
(hypothetical) RHEL 10 kernel in one fell swoop with a 4.13+ kernel
that no longer supports the 2-2-style fh's.  A client that had the
server mounted when it was running the 2.2 kernel might only be up for
a few hours, before the upgrade to RHEL 10 happened, and then the
client would get ESTALE errors.

Of course, I've stopped carrying about enterprise kernel support a
long time ago, so I just think that scenario is funny.  I recognize
that folks who work at Red Hat have to worry about such things --- and
I'm sorry.  :-)

In reality a server installed with RHEL 7.0 has probably died of old
age by now --- unless someone crazy is running it in a VMware VM
because they had some enterprise software package or some bar-code
printing module for which they don't have source code[1], and so they are
stuck on RHEL 7.0, even in 2017.  Have I mentioned I'm so glad I don't
have to worry these sorts of things any more?

RHEL 7 is current, I think you mean the 17-year-old Red Hat Linux 7.
Anyone that far back is on their own as far as any enterprise distro is
concerned.

There are some exceptions to the "lifetime of a mount" rule, none real
issues, I think:

	- fscache may keep fh's around across client boots, but I
	  suspect you just lose the benefit of the cache until it
	  expires data keyed under old filehandles and repopulates the
	  cache with new ones.

	- Does the client actually depend on stable filehandles across
	  client reboots if it might cache write data under a persistent
	  delegation?  But seeing as we don't even implement persistent
	  delegations, this is a non-issue.

	- nontraditional NFS clients could do any random thing.  NFS is
	  just a protocol, we have no idea how some weird application
	  that talks NFS directly to the server might use filehandles.
	  But this is purely hypothetical, I don't know of one.

--b.