Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: VM issue causing high CPU loads
Date: Thu, 3 Sep 2009 14:21:18 -0700
Message-ID: <7A24DF798E223B4C9864E8F92E8C93EC03F0AFB3@SACMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <20090903200550.GB5257@hostway.ca>
Thread-Topic: VM issue causing high CPU loads
Thread-Index: Acos0gQDjP3GE4VFSOOOHDyh16ct+gABkt2Q
From: "Muntz, Daniel" <Dan.Muntz@netapp.com>
To: "Simon Kirby" <sim@hostway.ca>,
       "Trond Myklebust" <trond.myklebust@fys.uio.no>
Cc: "Yohan" <ytordjman@corp.free.fr>,
       "Andrew Morton" <akpm@linux-foundation.org>,
       <linux-kernel@vger.kernel.org>, <linux-nfs@vger.kernel.org>,
       "Neil Brown" <neilb@suse.de>, "J. Bruce Fields" <bfields@fieldses.org>,
       <mikevs@xs4all.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3470
Lines: 75

Amen.  I understand that v4 wants to extend across domains, etc., but it
goes out of its way to prevent the use of uids/gids, which in the vast
majority of installations would work just fine and wouldn't incur the
overhead of the mapping/unmapping operations.  There's no reason
uids/gids couldn't coexist with string names.  If the 4.0 spec had a
slightly different version of this paragraph:

   To provide a greater degree of compatibility with previous versions
   of NFS (i.e., v2 and v3), which identified users and groups by 32-bit
   unsigned uid's and gid's, owner and group strings that consist of
   decimal numeric values with no leading zeros can be given a special
   interpretation by clients and servers which choose to provide such
   support.  The receiver may treat such a user or group string as
   representing the same user as would be represented by a v2/v3 uid or
   gid having the corresponding numeric value.  A server is not
   obligated to accept such a string, but may return an NFS4ERR_BADOWNER
   instead.  To avoid this mechanism being used to subvert user and
   group translation, so that a client might pass all of the owners and
   groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
   error when there is a valid translation for the user or owner
   designated in this way.  In that case, the client must use the
   appropriate name@domain string and not the special form for
   compatibility.

i.e., take out the "subvert" portion, and just plain allow string
representations of uids/gids, then at least the conversion would just be
an atoi and itoa.  Even better, allow the uids/gids to be used directly
and avoid the atoi/itoa, perhaps with a flag.  Either case is better
than idmapd and getting EDELAY and an X-second pause in odd places
because NFS has to go to userspace for a translation.

  -Dan Quixote

> -----Original Message-----
> From: Simon Kirby [mailto:sim@hostway.ca] 
> Sent: Thursday, September 03, 2009 1:06 PM
> To: Trond Myklebust
> Cc: Yohan; Andrew Morton; linux-kernel@vger.kernel.org; 
> linux-nfs@vger.kernel.org; Neil Brown; J. Bruce Fields; 
> mikevs@xs4all.net
> Subject: Re: VM issue causing high CPU loads
> 
> On Thu, Sep 03, 2009 at 10:02:06AM -0400, Trond Myklebust wrote:
> 
> > OK, so 16 hash buckets are likely to be filled with ~10^6 
> entries each.
> > I can see that might be a performance issue...
> 
> We have a similar setup with millions of UIDs over NFS 
> (currently NFSv3).
> I _wish_ there were a way to use NFSv4 without having to use 
> name-mapped UIDs and GIDs, since our user and group names 
> come from MySQL anyway, and are guaranteed to be consistent 
> across machines.
> 
> Why on earth does NFSv4 force the use of names?
> 
> I was considering hacking the code to stick IDs in there 
> anyway, but I haven't looked at the feasibility of this.  I 
> suspect this would break or complicate other things, but the 
> current NFSv4 design just seems like an incredible waste for 
> this case.
> 
> Simon-
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-nfs" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/