Re: [PATCH] nfsidmap: use multiple child keyrings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mar 24, 2014, at 3:51 PM, Steve Dickson <SteveD@xxxxxxxxxx> wrote:

>>> Finally, what -n value do plan on using? Maybe a blurb in the man page
>>> on what a good number is and why....
>> 
>> I've got this running now with -n160, since 
>> we have ~60K distinct uid/gid s.  Ideally, I'd like to re-submit 
>> this to self-scale which wouldn't require any sysadmin tuning, 
>> but I haven't had the time.  Really, this is just a quick fix 
>> for the brokenness that's in current RHEL and less-new Fedora.
> The brokenness in RHEL will be healing very soon... See 
> https://bugzilla.redhat.com/show_bug.cgi?id=1033708. RHEL is 
> basically going back to using rpc.idmapd on the client and
> nfsidmap is going away... It as just a bad dream... It never
> happen! ;-)

This BZ says the fix is coming in nfs-utils by removing the nfsidmap command.  But IIRC, unless the kernel side of the idmapper is changed, it will exec request-key for every lookup before falling back to the upcall, and there's no cache in front of that.  Isn't that going to have some performance problems?  I'm much more interested in getting the keyrings to work, since they seem to offer significant performance gains.

If RH is going to change the kernel side of the idmapper to only upcall, then I'd be satisfied to use that.

Ben--
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




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux