linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Simon Kirby <sim@hostway.ca>, linux-nfs@vger.kernel.org
Subject: Re: System CPU increasing on idle 2.6.36
Date: Wed, 15 Dec 2010 19:36:46 -0500	[thread overview]
Message-ID: <20101216003646.GG9646@fieldses.org> (raw)
In-Reply-To: <1292457489.3068.98.camel@heimdal.trondhjem.org>

On Wed, Dec 15, 2010 at 06:58:09PM -0500, Trond Myklebust wrote:
> On Wed, 2010-12-15 at 17:55 -0500, J. Bruce Fields wrote:
> > On Wed, Dec 15, 2010 at 05:29:28PM -0500, J. Bruce Fields wrote:
> > > On Wed, Dec 15, 2010 at 05:15:46PM -0500, Trond Myklebust wrote:
> > > > I'm quite happy to accept that my user may map to completely different
> > > > identities on the server as I switch authentication schemes. Fixing that
> > > > is indeed the administrator's problem.
> > > > 
> > > > I'm thinking of the simple case of creating a file, and then expecting
> > > > to see that file appear labelled with the correct user id when I do 'ls
> > > > -l'. That should work irrespectively of the authentication scheme that I
> > > > choose.
> > > > 
> > > > In other words, if I authenticate as 'trond' on my client or to the
> > > > kerberos server, then do
> > > > 
> > > >         touch foo
> > > >         ls -l foo
> > > > 
> > > > I should see a file that is owned by 'trond'.
> > > 
> > > Thanks, understood; but then, this isn't about behavior that occurs when
> > > a user *changes* authentication flavors.
> > > 
> > > It's about what happens when someone sets nfs4_disable_idmapping but
> > > shouldn't have.
> > 
> > In other words, to make sure I understand:
> > 
> > 	- Is this switching-on-auth flavor *just* there to protect
> > 	  confused administrators against themselves?
> > 	- Or is there some reasons someone who knew what they were doing
> > 	  would actually *need* that behavior?
> 
> It is there to ensure that you can use different type of authentication
> when speaking to different servers, and still have it work without the
> administrator having to add special mount options.

Oh, OK--now I understand, thanks!  Then it really is just a restricted
sort of per-mountpoint idmapping.

As such I'm not sure I understand the relative merits of that versus
(possibly per-server) idmapd configuration.  But at least it seems
tolerable.

The biggest remaining problem either way is that the user experience on
an NFSv3->NFSv4 upgrade is still:

	- oh, look, file owners look all wrong.
	- go find documentation of the needed configuration
	  (domain setting in /etc/idmapd.conf, or nfs4_disable_idmapping
	  option)

--b.

> As I've said before, the uid-on-the-wire behaviour only makes sense with
> AUTH_SYS. It adds no value when authenticating using principals, and
> will in many (most?) cases end up doing the wrong thing.
> 
> Trond
> 
> -- 
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
> 

  reply	other threads:[~2010-12-16  0:36 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-08 21:25 System CPU increasing on idle 2.6.36 Simon Kirby
2010-12-08 21:53 ` Trond Myklebust
2010-12-08 22:36   ` Simon Kirby
2010-12-09  4:37     ` Trond Myklebust
2010-12-14 23:38       ` Simon Kirby
2010-12-15  1:10         ` Simon Kirby
2010-12-15  1:56           ` Simon Kirby
2010-12-15 18:08             ` J. Bruce Fields
2010-12-15 18:22               ` Trond Myklebust
2010-12-15 18:38                 ` J. Bruce Fields
2010-12-15 19:33                   ` Trond Myklebust
2010-12-15 19:49                     ` J. Bruce Fields
2010-12-15 19:57                       ` Trond Myklebust
2010-12-15 20:19                         ` J. Bruce Fields
2010-12-15 20:32                           ` Trond Myklebust
2010-12-15 21:48                             ` J. Bruce Fields
2010-12-15 22:15                               ` Trond Myklebust
2010-12-15 22:29                                 ` J. Bruce Fields
2010-12-15 22:55                                   ` J. Bruce Fields
2010-12-15 23:58                                     ` Trond Myklebust
2010-12-16  0:36                                       ` J. Bruce Fields [this message]
2011-09-27  0:39   ` NFS client growing system CPU Simon Kirby
2011-09-27 11:42     ` Trond Myklebust
2011-09-27 16:49       ` Simon Kirby
2011-09-27 17:04         ` Trond Myklebust
2011-09-28 19:58           ` Simon Kirby
2011-09-30  0:58             ` Simon Kirby
2011-09-30  1:11               ` Myklebust, Trond
2011-10-05 23:07                 ` Simon Kirby
2010-12-18  1:08 ` System CPU increasing on idle 2.6.36 Simon Kirby
2010-12-21 20:31   ` Mark Moseley
2010-12-29 22:03   ` Simon Kirby
2011-01-04 17:42     ` Mark Moseley
2011-01-04 21:40       ` Simon Kirby
2011-01-05 19:43         ` Mark Moseley
2011-01-07 18:05           ` Mark Moseley
2011-01-07 18:12             ` Mark Moseley
2011-01-07 19:33               ` Mark Moseley
2011-01-08  0:52             ` Simon Kirby
2011-01-08  1:30               ` Mark Moseley

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=20101216003646.GG9646@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=Trond.Myklebust@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=sim@hostway.ca \
    /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;
as well as URLs for NNTP newsgroup(s).