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@xxxxxxxxxx] > Sent: Thursday, September 03, 2009 1:06 PM > To: Trond Myklebust > Cc: Yohan; Andrew Morton; linux-kernel@xxxxxxxxxxxxxxx; > linux-nfs@xxxxxxxxxxxxxxx; Neil Brown; J. Bruce Fields; > mikevs@xxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at > http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
