Message-ID: <1326149428.10779.10.camel@lade.trondhjem.org>
Date:	Mon, 09 Jan 2012 17:50:28 -0500
From:	Trond Myklebust <Trond.Myklebust@...app.com>
To:	Wolfgang Walter <wolfgang.walter@...m.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: RE: [GIT PULL] Please pull NFS client bugfixes and cleanups

On Mon, 2012-01-09 at 14:28 -0800, Myklebust, Trond wrote: 
> > -----Original Message-----
> > From: Wolfgang Walter [mailto:wolfgang.walter@...m.de]
> > Sent: Monday, January 09, 2012 5:15 PM
> > To: Myklebust, Trond
> > Cc: Linus Torvalds; linux-nfs@...r.kernel.org; linux-kernel@...r.kernel.org
> > Subject: Re: [GIT PULL] Please pull NFS client bugfixes and cleanups
> > 
> > On Monday 09 January 2012, Trond Myklebust wrote:
> > > Hi Linus,
> > >
> > > Please pull from the "nfs-for-3.3" branch of the repository at
> > >
> > >    git pull git://git.linux-nfs.org/projects/trondmy/linux-nfs.git
> > > nfs-
> > for-3.3
> > >
> > > This will update the following files through the appended changesets.
> > >
> > >   Cheers,
> > >     Trond
> > >
> > >
> > > commit 074b1d12fe2500d7d453902f9266e6674b30d84c
> > > Author: Trond Myklebust <Trond.Myklebust@...app.com>
> > > Date:   Mon Jan 9 13:46:26 2012 -0500
> > >
> > >     NFSv4: Change the default setting of the nfs4_disable_idmapping
> > parameter
> > >
> > >     Now that the use of numeric uids/gids is officially sanctioned in
> > >     RFC3530bis, it is time to change the default here to 'enabled'.
> > >
> > >     By doing so, we ensure that NFSv4 copies the behaviour of NFSv3
> > > when
> > we're
> > >     using the default AUTH_SYS authentication (i.e. when the client uses the
> > >     numeric uids/gids as authentication tokens), so that when new files are
> > >     created, they will appear to have the correct user/group.
> > >     It also fixes a number of backward compatibility issues when migrating
> > >     from NFSv3 to NFSv4 on a platform where the server uses different
> > uid/gid
> > >     mappings than the client.
> > >
> > >     Note also that this setting has been successfully tested against servers
> > >     that do not support numeric uids/gids at several
> > Connectathon/Bakeathon
> > >     events at this point, and the fall back to using string names/groups has
> > >     been shown to work well in all those test cases.
> > >
> > >     Signed-off-by: Trond Myklebust <Trond.Myklebust@...app.com>
> > >
> > 
> > 
> > Does this mean that one has to modify all one's clients to get the old
> > behaviour?
> > 
> > I'm not sure if this is a really good idea. I don't see the advantage. This will
> > break a lot of existing installations when upgrading to >=3.3. And someone
> > migrating from NFSv3 to NFSv4 has to give some thoughts to it anyway.
> 
> Please read the changelog and documentation:
> 
> If your server doesn’t support numeric uids/gids, then you will see _no_ change in behaviour.
> 
> If your server does support numeric uids/gids, and has the same mapping between numeric uids/gids and username/groupname as your clients, then you will see _no_ change in behaviour.
> 
> If your server does support numeric uids/gids, but the mapping between numeric uids/gids and username/groupname differs between server and client (e.g.. uid=20 maps to different users on the client and server) then you already had a problem in that creating the file using NFSv4 would result in you seeing the wrong owner and/or group. If this case, and this case only, the change to nfs4_disable_idmapper will result in you now seeing the correct owner/group for these files (just as if you were using NFSv3).
> 
> IOW: the only people who will want to use the old setting are those with broken servers that return incorrect errors when confronted with a numeric uid/gid. We have found no evidence that any such servers exist during the last full year of testing.

Actually, let me amend that last statement.

The only broken server we found was the Linux server, which was
returning NFS4ERR_BADNAME in a situation where the protocol specified
that it should be returning NFS4ERR_BADOWNER. This is why we have the
little comment "The following works around a Linux server bug!" in the
client code.
Commit f6af99ec1b261e21219d5eba99e3af48fc6c32d4 (nfsd4: name->id mapping
should fail with BADOWNER not BADNAME) fixed that server bug exactly one
year ago, and the fix was subsequently pushed to stable@...nel.org...

IOW: unless you find something earth-shattering when you enable the
option in your existing clients (the option has existed since 2.6.39),
I'd prefer to change the default as soon as possible in order to fix the
existing brokenness for those people running NFSv4 without the benefit
of an ldap/nis/yp server to ensure a homogeneous uid/gid name space...

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists