mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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-kernel@vger.kernel.org
Subject: Re: [GIT PULL] Please pull NFS client bugfixes and cleanups
Date: Tue, 10 Jan 2012 01:49:00 +0100	[thread overview]
Message-ID: <201201100149.00716.wolfgang.walter@stwm.de> (raw)
In-Reply-To: <1326149428.10779.10.camel@lade.trondhjem.org>

On Monday 09 January 2012, Trond Myklebust wrote:
> On Mon, 2012-01-09 at 14:28 -0800, Myklebust, Trond wrote: 
> > > -----Original Message-----
> > Please read the changelog and documentation:
> > 
> > If your server doesn’t support numeric uids/gids, then you will see _no_ 
> > change in behaviour.

Hmm, what does that mean exactly? Does a linux nfs4-server support numeric 
uids/gids? If yes, by default or do I need do set an option?

> > 
> > 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).

The only thing I can say is that in the moment client and server are using 
rpc.idmapd and it works perfectly well.

> > 
> > 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@kernel.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...

I always thought that the idmapper with its translation were exactly for that 
case. If I have a homogenous uid/gid name space why would I want to use names 
and translate anyway?


Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

  reply	other threads:[~2012-01-10  0:49 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
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 [this message]
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=201201100149.00716.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®