Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1680650 > unrolled thread

Re: [PATCH] fs: ext4: inode->i_generation not assigned 0.

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] fs: ext4: inode->i_generation not assigned 0. "Darrick J. Wong" <darrick.wong@oracle.com> - 2017-07-04 06:10 +0200
    Re: [PATCH] fs: ext4: inode->i_generation not assigned 0. "J. Bruce Fields" <bfields@fieldses.org> - 2017-07-05 03:20 +0200
      Re: [PATCH] fs: ext4: inode->i_generation not assigned 0. "Darrick J. Wong" <darrick.wong@oracle.com> - 2017-07-05 21:30 +0200
        Re: [PATCH] fs: ext4: inode->i_generation not assigned 0. Theodore Ts'o <tytso@mit.edu> - 2017-07-05 22:30 +0200
          Re: [PATCH] fs: ext4: inode->i_generation not assigned 0. Jeff Layton <jlayton@redhat.com> - 2017-07-07 13:00 +0200
            Re: [PATCH] fs: ext4: inode->i_generation not assigned 0. Theodore Ts'o <tytso@mit.edu> - 2017-07-07 18:00 +0200
              Re: [PATCH] fs: ext4: inode->i_generation not assigned 0. Jeff Layton <jlayton@redhat.com> - 2017-07-07 18:20 +0200
                Re: [PATCH] fs: ext4: inode->i_generation not assigned 0. "J. Bruce Fields" <bfields@fieldses.org> - 2017-07-07 18:50 +0200
        Re: [PATCH] fs: ext4: inode->i_generation not assigned 0. "J. Bruce Fields" <bfields@fieldses.org> - 2017-07-05 22:50 +0200
          Re: [PATCH] fs: ext4: inode->i_generation not assigned 0. NeilBrown <neilb@suse.com> - 2017-07-06 03:10 +0200
            Re: [PATCH] fs: ext4: inode->i_generation not assigned 0. "J. Bruce Fields" <bfields@fieldses.org> - 2017-07-06 04:50 +0200

#1680650 — Re: [PATCH] fs: ext4: inode->i_generation not assigned 0.

On Thu, Jun 29, 2017 at 02:50:22PM -0400, J. Bruce Fields wrote:
> On Thu, Jun 29, 2017 at 02:30:53PM -0400, J. Bruce Fields wrote:
> > On Thu, Jun 29, 2017 at 10:25:28AM -0700, Darrick J. Wong wrote:
> > > Was there ever a version of NFS (or more generally callers of the
> > > exportfs code) that couldn't deal with i_generation in the file handle,
> > > and therefore we invented this generation hack to work around the loss
> > > of the generation information?
> > > 
> > > There's a comment in xfs_fs_encode_fh about not supporting 64bit inodes
> > > with subtree_check (which seems to require one ino/gen pair for the file
> > > and a second pair for the file's parent) on NFSv2 because v2 doesn't
> > > provide enough space for all the file handle information, but that's the
> > > furthest I got with lazy-mining the git history. :)
> > 
> > There's a comment in fs/ext4/super.c:ext4_nfs_get_inode
> > 
> > 	* Currently we don't know the generation for parent directory, so
> > 	* a generation of 0 means "accept any"
> > 
> > But I don't see that used.
> > 
> > It was used once upon a time; I see it actually used in old 2.5 code in
> > nfsd_get_dentry.  Hm.
> 
> Oh, maybe it's here in fs/libfs.c:generic_fh_to_parent:
> 
> 	switch (fh_type) {
> 	case FILEID_INO32_GEN_PARENT:
> 		inode = get_inode(sb, fid->i32.parent_ino,
>         			  (fh_len > 3 ? fid->i32.parent_gen : 0));
> 		break;
> 	}
> 
> I'm not sure under what conditions that filehandle encoding is used.

The best guess I can come up with is the old nfs_fhbase_old style handles,
which (afaict) do not carry parent i_generation?

--D

> 
> --b.

[toc] | [next] | [standalone]

#1681237

On Mon, Jul 03, 2017 at 09:04:46PM -0700, Darrick J. Wong wrote:
> On Thu, Jun 29, 2017 at 02:50:22PM -0400, J. Bruce Fields wrote:
> > On Thu, Jun 29, 2017 at 02:30:53PM -0400, J. Bruce Fields wrote:
> > > On Thu, Jun 29, 2017 at 10:25:28AM -0700, Darrick J. Wong wrote:
> > > > Was there ever a version of NFS (or more generally callers of the
> > > > exportfs code) that couldn't deal with i_generation in the file handle,
> > > > and therefore we invented this generation hack to work around the loss
> > > > of the generation information?
> > > > 
> > > > There's a comment in xfs_fs_encode_fh about not supporting 64bit inodes
> > > > with subtree_check (which seems to require one ino/gen pair for the file
> > > > and a second pair for the file's parent) on NFSv2 because v2 doesn't
> > > > provide enough space for all the file handle information, but that's the
> > > > furthest I got with lazy-mining the git history. :)
> > > 
> > > There's a comment in fs/ext4/super.c:ext4_nfs_get_inode
> > > 
> > > 	* Currently we don't know the generation for parent directory, so
> > > 	* a generation of 0 means "accept any"
> > > 
> > > But I don't see that used.
> > > 
> > > It was used once upon a time; I see it actually used in old 2.5 code in
> > > nfsd_get_dentry.  Hm.
> > 
> > Oh, maybe it's here in fs/libfs.c:generic_fh_to_parent:
> > 
> > 	switch (fh_type) {
> > 	case FILEID_INO32_GEN_PARENT:
> > 		inode = get_inode(sb, fid->i32.parent_ino,
> >         			  (fh_len > 3 ? fid->i32.parent_gen : 0));
> > 		break;
> > 	}
> > 
> > I'm not sure under what conditions that filehandle encoding is used.
> 
> The best guess I can come up with is the old nfs_fhbase_old style handles,
> which (afaict) do not carry parent i_generation?

Yeah, I just couldn't tell in the time I looked whether they could still
be handed out.

If not, then the only way they'd still be used is if a client had a
server continually mounted while the server was upgraded from a kernel
that still handed out the old filehandle.

So if they haven't been given out for long enough it's possible nobody
would notice if we dropped support.

But, I didn't get far enough to figure that out.

--b.

[toc] | [prev] | [next] | [standalone]

#1681732

On Tue, Jul 04, 2017 at 09:15:34PM -0400, J. Bruce Fields wrote:
> On Mon, Jul 03, 2017 at 09:04:46PM -0700, Darrick J. Wong wrote:
> > On Thu, Jun 29, 2017 at 02:50:22PM -0400, J. Bruce Fields wrote:
> > > On Thu, Jun 29, 2017 at 02:30:53PM -0400, J. Bruce Fields wrote:
> > > > On Thu, Jun 29, 2017 at 10:25:28AM -0700, Darrick J. Wong wrote:
> > > > > Was there ever a version of NFS (or more generally callers of the
> > > > > exportfs code) that couldn't deal with i_generation in the file handle,
> > > > > and therefore we invented this generation hack to work around the loss
> > > > > of the generation information?
> > > > > 
> > > > > There's a comment in xfs_fs_encode_fh about not supporting 64bit inodes
> > > > > with subtree_check (which seems to require one ino/gen pair for the file
> > > > > and a second pair for the file's parent) on NFSv2 because v2 doesn't
> > > > > provide enough space for all the file handle information, but that's the
> > > > > furthest I got with lazy-mining the git history. :)
> > > > 
> > > > There's a comment in fs/ext4/super.c:ext4_nfs_get_inode
> > > > 
> > > > 	* Currently we don't know the generation for parent directory, so
> > > > 	* a generation of 0 means "accept any"
> > > > 
> > > > But I don't see that used.
> > > > 
> > > > It was used once upon a time; I see it actually used in old 2.5 code in
> > > > nfsd_get_dentry.  Hm.
> > > 
> > > Oh, maybe it's here in fs/libfs.c:generic_fh_to_parent:
> > > 
> > > 	switch (fh_type) {
> > > 	case FILEID_INO32_GEN_PARENT:
> > > 		inode = get_inode(sb, fid->i32.parent_ino,
> > >         			  (fh_len > 3 ? fid->i32.parent_gen : 0));
> > > 		break;
> > > 	}
> > > 
> > > I'm not sure under what conditions that filehandle encoding is used.
> > 
> > The best guess I can come up with is the old nfs_fhbase_old style handles,
> > which (afaict) do not carry parent i_generation?
> 
> Yeah, I just couldn't tell in the time I looked whether they could still
> be handed out.
> 
> If not, then the only way they'd still be used is if a client had a
> server continually mounted while the server was upgraded from a kernel
> that still handed out the old filehandle.
> 
> So if they haven't been given out for long enough it's possible nobody
> would notice if we dropped support.
> 
> But, I didn't get far enough to figure that out.

Hmm, so looking back through prehistory, Linux prior to 2.3.51 (11 March
2000) gave out the old dentry style fhandles.  After that, the kernel
only gave out the new style handles that we still use today.  In 2.4.6
(4 July 2001) the behavior was modified again to chain handle types,
i.e. if the client passed in an old style handle then it would get
another old style handle back.  The changelog for -pre9 says that this
was done for compatibility reasons.

So, what's the probability that there are clients out there that started
talking to a 2.2-based knfsd and will now want to talk to a modern 4.13
kernel seventeen years later?  (Do nfs handles persist across client
restarts/remounts?)

--D

> 
> --b.

[toc] | [prev] | [next] | [standalone]

#1681780

On Wed, Jul 05, 2017 at 12:19:33PM -0700, Darrick J. Wong wrote:
> 
> So, what's the probability that there are clients out there that started
> talking to a 2.2-based knfsd and will now want to talk to a modern 4.13
> kernel seventeen years later?  (Do nfs handles persist across client
> restarts/remounts?)

It's whether or not nfs handles persist across server restarts which
would be the more interesting question.  So if you had a NAS box that
was using a Linux 2.2 kernel, and you had clients access the box, and
then that box gets upgraded to use a 4.13 kernel, what happens?

In the ideal world, the client wouldn't notice, and its 2.2-based file
handles that it obtained while the 2.2 kernel was running would
continue to work after the box came back up running the new 4.13
kernel.

To be honest, I'm not sure I care that much, but I don't use NFS much
if at all these days myself.  And in reality, what's the chance that
an NAS box vendor would continue to support a box that is 17 years old
and provide an upgrade for it?  (OK, everyone can stop laughing now. :-)

    	       	       	   	- Ted

[toc] | [prev] | [next] | [standalone]

#1683120

On Wed, 2017-07-05 at 16:27 -0400, Theodore Ts'o wrote:
> On Wed, Jul 05, 2017 at 12:19:33PM -0700, Darrick J. Wong wrote:
> > 
> > So, what's the probability that there are clients out there that started
> > talking to a 2.2-based knfsd and will now want to talk to a modern 4.13
> > kernel seventeen years later?  (Do nfs handles persist across client
> > restarts/remounts?)
> 
> It's whether or not nfs handles persist across server restarts which
> would be the more interesting question.  So if you had a NAS box that
> was using a Linux 2.2 kernel, and you had clients access the box, and
> then that box gets upgraded to use a 4.13 kernel, what happens?
> 
> In the ideal world, the client wouldn't notice, and its 2.2-based file
> handles that it obtained while the 2.2 kernel was running would
> continue to work after the box came back up running the new 4.13
> kernel.
> 

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.

> To be honest, I'm not sure I care that much, but I don't use NFS much
> if at all these days myself.  And in reality, what's the chance that
> an NAS box vendor would continue to support a box that is 17 years old
> and provide an upgrade for it?  (OK, everyone can stop laughing now. :-)

Agreed. I think we're safe enough to remove this support.

If we were really concerned about it, we could move support for it under
a Kconfig option that defaults to "off" for now, and then we could plan
to just drop it in a couple of years.

Vendors that thought they might need it could enable it and speak up
with their use case if they wanted to keep it in for future releases.
Most likely though, no-one will care.
-- 
Jeff Layton <jlayton@redhat.com>

[toc] | [prev] | [next] | [standalone]

#1683272

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.

[toc] | [prev] | [next] | [standalone]

#1683286

On Fri, 2017-07-07 at 11:51 -0400, Theodore Ts'o wrote:
> 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.

Yep, exactly. An abrupt upgrade like that is always a possibility, but
it's pretty unlikely, and I don't have a ton of sympathy for anyone who
does that.

I guess another thing we could do as an interim step is to add a
scary-looking printk that fires when someone sends us one of these
really old-style filehandles.

That won't help the poor bastard who updates the host directly from
v2.2-era kernel to the version that eventually removes support for the
old filehandles. It might give us an idea of whether there are still
clients in the field that are still using them though.

-- 
Jeff Layton <jlayton@redhat.com>

[toc] | [prev] | [next] | [standalone]

#1683310

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:
> > 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?

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.

[toc] | [prev] | [next] | [standalone]

#1681798

On Wed, Jul 05, 2017 at 12:19:33PM -0700, Darrick J. Wong wrote:
> On Tue, Jul 04, 2017 at 09:15:34PM -0400, J. Bruce Fields wrote:
> > On Mon, Jul 03, 2017 at 09:04:46PM -0700, Darrick J. Wong wrote:
> > > On Thu, Jun 29, 2017 at 02:50:22PM -0400, J. Bruce Fields wrote:
> > > > On Thu, Jun 29, 2017 at 02:30:53PM -0400, J. Bruce Fields wrote:
> > > > > On Thu, Jun 29, 2017 at 10:25:28AM -0700, Darrick J. Wong wrote:
> > > > > > Was there ever a version of NFS (or more generally callers of the
> > > > > > exportfs code) that couldn't deal with i_generation in the file handle,
> > > > > > and therefore we invented this generation hack to work around the loss
> > > > > > of the generation information?
> > > > > > 
> > > > > > There's a comment in xfs_fs_encode_fh about not supporting 64bit inodes
> > > > > > with subtree_check (which seems to require one ino/gen pair for the file
> > > > > > and a second pair for the file's parent) on NFSv2 because v2 doesn't
> > > > > > provide enough space for all the file handle information, but that's the
> > > > > > furthest I got with lazy-mining the git history. :)
> > > > > 
> > > > > There's a comment in fs/ext4/super.c:ext4_nfs_get_inode
> > > > > 
> > > > > 	* Currently we don't know the generation for parent directory, so
> > > > > 	* a generation of 0 means "accept any"
> > > > > 
> > > > > But I don't see that used.
> > > > > 
> > > > > It was used once upon a time; I see it actually used in old 2.5 code in
> > > > > nfsd_get_dentry.  Hm.
> > > > 
> > > > Oh, maybe it's here in fs/libfs.c:generic_fh_to_parent:
> > > > 
> > > > 	switch (fh_type) {
> > > > 	case FILEID_INO32_GEN_PARENT:
> > > > 		inode = get_inode(sb, fid->i32.parent_ino,
> > > >         			  (fh_len > 3 ? fid->i32.parent_gen : 0));
> > > > 		break;
> > > > 	}
> > > > 
> > > > I'm not sure under what conditions that filehandle encoding is used.
> > > 
> > > The best guess I can come up with is the old nfs_fhbase_old style handles,
> > > which (afaict) do not carry parent i_generation?
> > 
> > Yeah, I just couldn't tell in the time I looked whether they could still
> > be handed out.
> > 
> > If not, then the only way they'd still be used is if a client had a
> > server continually mounted while the server was upgraded from a kernel
> > that still handed out the old filehandle.
> > 
> > So if they haven't been given out for long enough it's possible nobody
> > would notice if we dropped support.
> > 
> > But, I didn't get far enough to figure that out.
> 
> Hmm, so looking back through prehistory, Linux prior to 2.3.51 (11 March
> 2000) gave out the old dentry style fhandles.  After that, the kernel
> only gave out the new style handles that we still use today.  In 2.4.6
> (4 July 2001) the behavior was modified again to chain handle types,
> i.e. if the client passed in an old style handle then it would get
> another old style handle back.  The changelog for -pre9 says that this
> was done for compatibility reasons.

Yeah, you're supposed to be able to reboot your NFS server for a kernel
upgrade without your client applications experiencing anything worse
than a temporary hang while you wait for the server to come back up.
So, changing the filehandle format and returning ESTALE to everyone
would be unpopular.

> So, what's the probability that there are clients out there that started
> talking to a 2.2-based knfsd and will now want to talk to a modern 4.13
> kernel seventeen years later?

I think it's unlikely enough that we could drop that code; cc'ing Neil
in case we overlooked anything.

> (Do nfs handles persist across client restarts/remounts?)

No.

(Well, with maybe a couple exceptions (fscache and persistent NFSv4
delegations) but neither seem relevant here.)

--b.

[toc] | [prev] | [next] | [standalone]

#1681987

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jul 05 2017, J. Bruce Fields wrote:

> On Wed, Jul 05, 2017 at 12:19:33PM -0700, Darrick J. Wong wrote:
>> On Tue, Jul 04, 2017 at 09:15:34PM -0400, J. Bruce Fields wrote:
>> > On Mon, Jul 03, 2017 at 09:04:46PM -0700, Darrick J. Wong wrote:
>> > > On Thu, Jun 29, 2017 at 02:50:22PM -0400, J. Bruce Fields wrote:
>> > > > On Thu, Jun 29, 2017 at 02:30:53PM -0400, J. Bruce Fields wrote:
>> > > > > On Thu, Jun 29, 2017 at 10:25:28AM -0700, Darrick J. Wong wrote:
>> > > > > > Was there ever a version of NFS (or more generally callers of the
>> > > > > > exportfs code) that couldn't deal with i_generation in the file handle,
>> > > > > > and therefore we invented this generation hack to work around the loss
>> > > > > > of the generation information?
>> > > > > > 
>> > > > > > There's a comment in xfs_fs_encode_fh about not supporting 64bit inodes
>> > > > > > with subtree_check (which seems to require one ino/gen pair for the file
>> > > > > > and a second pair for the file's parent) on NFSv2 because v2 doesn't
>> > > > > > provide enough space for all the file handle information, but that's the
>> > > > > > furthest I got with lazy-mining the git history. :)
>> > > > > 
>> > > > > There's a comment in fs/ext4/super.c:ext4_nfs_get_inode
>> > > > > 
>> > > > > 	* Currently we don't know the generation for parent directory, so
>> > > > > 	* a generation of 0 means "accept any"
>> > > > > 
>> > > > > But I don't see that used.
>> > > > > 
>> > > > > It was used once upon a time; I see it actually used in old 2.5 code in
>> > > > > nfsd_get_dentry.  Hm.
>> > > > 
>> > > > Oh, maybe it's here in fs/libfs.c:generic_fh_to_parent:
>> > > > 
>> > > > 	switch (fh_type) {
>> > > > 	case FILEID_INO32_GEN_PARENT:
>> > > > 		inode = get_inode(sb, fid->i32.parent_ino,
>> > > >         			  (fh_len > 3 ? fid->i32.parent_gen : 0));
>> > > > 		break;
>> > > > 	}
>> > > > 
>> > > > I'm not sure under what conditions that filehandle encoding is used.
>> > > 
>> > > The best guess I can come up with is the old nfs_fhbase_old style handles,
>> > > which (afaict) do not carry parent i_generation?
>> > 
>> > Yeah, I just couldn't tell in the time I looked whether they could still
>> > be handed out.
>> > 
>> > If not, then the only way they'd still be used is if a client had a
>> > server continually mounted while the server was upgraded from a kernel
>> > that still handed out the old filehandle.
>> > 
>> > So if they haven't been given out for long enough it's possible nobody
>> > would notice if we dropped support.
>> > 
>> > But, I didn't get far enough to figure that out.
>> 
>> Hmm, so looking back through prehistory, Linux prior to 2.3.51 (11 March
>> 2000) gave out the old dentry style fhandles.  After that, the kernel
>> only gave out the new style handles that we still use today.  In 2.4.6
>> (4 July 2001) the behavior was modified again to chain handle types,
>> i.e. if the client passed in an old style handle then it would get
>> another old style handle back.  The changelog for -pre9 says that this
>> was done for compatibility reasons.
>
> Yeah, you're supposed to be able to reboot your NFS server for a kernel
> upgrade without your client applications experiencing anything worse
> than a temporary hang while you wait for the server to come back up.
> So, changing the filehandle format and returning ESTALE to everyone
> would be unpopular.
>
>> So, what's the probability that there are clients out there that started
>> talking to a 2.2-based knfsd and will now want to talk to a modern 4.13
>> kernel seventeen years later?
>
> I think it's unlikely enough that we could drop that code; cc'ing Neil
> in case we overlooked anything.

While I remain a fan of maintaining forward/backward compatibility as
much as possible, 15 years is probably more than I can realistically
hope for.
As you say, a generation number of '0' is only special when old-style
file handles are used, with the "subtree_check" export option.  They are
unlikely to have been used recently.

However, I note that include/linux/exportfs.h says:

	/*
	 * 32bit inode number, 32 bit generation number,
	 * 32 bit parent directory inode number.
	 */
	FILEID_INO32_GEN_PARENT = 2,

This could be seen as misleading.
Some code that reports that fid_type includes the directory generation
number.  Some other code (cephfs, squashfs) doesn't even include the
generation number for the inode (which is OK for squashfs as it is
write-only).  I could find no code that matches this documentation.

I was never a fan of having generic fid_types.  Except for 0 and 255,
these numbers are generated and interpreted by individual filesystems,
and there is no reason that they should agree on the interpretation (and
as we see here, they don't).

But for the main point of your question: I see no problem with removing
nfs_fhbase_old and related code, and that includes the special handling
of generation number zero.

Thanks,
NeilBrown

>
>> (Do nfs handles persist across client restarts/remounts?)
>
> No.
>
> (Well, with maybe a couple exceptions (fscache and persistent NFSv4
> delegations) but neither seem relevant here.)
>
> --b.

[toc] | [prev] | [next] | [standalone]

#1682021

On Thu, Jul 06, 2017 at 11:08:27AM +1000, NeilBrown wrote:
> On Wed, Jul 05 2017, J. Bruce Fields wrote:
> 
> > On Wed, Jul 05, 2017 at 12:19:33PM -0700, Darrick J. Wong wrote:
> >> So, what's the probability that there are clients out there that started
> >> talking to a 2.2-based knfsd and will now want to talk to a modern 4.13
> >> kernel seventeen years later?
> >
> > I think it's unlikely enough that we could drop that code;

Wow, that was a terrible sentence.  What I meant was: I think it's
unlikely that such a client exists, therefore I'm OK with dropping that
code.

Anyway:

> cc'ing Neil
> > in case we overlooked anything.
> 
> While I remain a fan of maintaining forward/backward compatibility as
> much as possible, 15 years is probably more than I can realistically
> hope for.
> As you say, a generation number of '0' is only special when old-style
> file handles are used, with the "subtree_check" export option.  They are
> unlikely to have been used recently.
...
> But for the main point of your question: I see no problem with removing
> nfs_fhbase_old and related code, and that includes the special handling
> of generation number zero.

So, we agree, OK.

I dunno if this is actually urgent.  But it'd be nice to clean out.

--b.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web