From: Wolfgang Walter <wolfgang.walter@stwm.de>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Please pull NFS client bugfixes and cleanups
Date: Mon, 9 Jan 2012 23:15:27 +0100 [thread overview]
Message-ID: <201201092315.28230.wolfgang.walter@stwm.de> (raw)
In-Reply-To: <1326142671.9041.1.camel@lade.trondhjem.org>
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@netapp.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@netapp.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.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
next prev parent reply other threads:[~2012-01-09 22:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-09 20:57 Trond Myklebust
2012-01-09 22:15 ` Wolfgang Walter [this message]
2012-01-09 22:28 ` Myklebust, Trond
[not found] ` <A4C37DBDA23D504B9F8F6ED1AD1F4F3245A40D11@SACMVEXC2-PRD.hq.netapp.com>
2012-01-09 22:50 ` Trond Myklebust
2012-01-10 0:49 ` Wolfgang Walter
2012-01-10 1:53 ` Trond Myklebust
2012-01-10 10:53 ` Wolfgang Walter
2012-01-10 13:38 ` Trond Myklebust
2012-01-10 17:22 ` Wolfgang Walter
2012-01-10 17:47 ` Myklebust, Trond
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201201092315.28230.wolfgang.walter@stwm.de \
--to=wolfgang.walter@stwm.de \
--cc=Trond.Myklebust@netapp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®