On Tue, 2012-07-31 at 15:42 +0100, David Howells wrote:
> The NFS idmapper has two key types (normal and legacy) but should only use one
> if it can - otherwise it risks having twice as many keys as it would otherwise
> need.
Why is this? Do we add keys in the case where the 'normal' upcall fails?
> Get rid of the legacy key type and have the normal key type have a
> .request_key() op. The choice of which instantiation method is then made by
> the upcaller, in order:
>
> (1) If there's no auxdata, the normal method is called, invoking
> /sbin/request-key.
>
> (2) If there's something attached to the idmapper pipe (rpc.idmapd) then use
> that.
>
> (3) Fall back to (1).
>
> Note that this does change the prioritisation of normal vs legacy if both are
> available.
We don't want to do this. The legacy call is 100% serialised, so this
means that we end up choosing the non-scalable alternative.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
