> -----Original Message----- > From: Wolfgang Walter [mailto:wolfgang.walter@xxxxxxx] > Sent: Monday, January 09, 2012 5:15 PM > To: Myklebust, Trond > Cc: Linus Torvalds; linux-nfs@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx > 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@xxxxxxxxxx> > > 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@xxxxxxxxxx> > > > > > 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. Trond ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
