Re: [PATCH] fs: ext4: inode->i_generation not assigned 0.
From: Theodore Ts'o <tytso@mit.edu>
Date: 2017-07-07 15:51:33
Also in:
linux-fsdevel, linux-xfs, lkml
On Fri, Jul 07, 2017 at 06:51:37AM -0400, Jeff Layton wrote:
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? - Ted [1] That wasn't a made up example; I once visited a customer on site, back in the day, that had that exact problem, and so they were stuck on some antique version of RHEL, and they expected me to help them.