From: NeilBrown <neilb@suse.de>
To: Anna Schumaker <bjschuma@netapp.com>
Cc: NFS <linux-nfs@vger.kernel.org>, David Howells <dhowells@redhat.com>
Subject: Re: What is the long term fix for the idmapper key-quota problem.
Date: Wed, 23 Oct 2013 08:30:19 +1100 [thread overview]
Message-ID: <20131023083019.7dfc39f9@notabene.brown> (raw)
In-Reply-To: <52669069.5050700@netapp.com>
[-- Attachment #1: Type: text/plain, Size: 2537 bytes --]
On Tue, 22 Oct 2013 10:49:13 -0400 Anna Schumaker <bjschuma@netapp.com> wrote:
> On Mon 21 Oct 2013 01:05:14 AM EDT, NeilBrown wrote:
> >
> > Hi,
> > as you probably know, request_key() imposes a quota on
> > the number of keys that can be requested, which by default is quite low (200).
> > When idmap exceeds this quota, request_key() returns an error and
> > the result is userspace sees "nobody" as the owner.
> >
> > A short term fix is to fiddle some sysctl values, but I wonder if any long
> > term fix is being planned.
>
> I don't have anything planned.
Maybe it is time to start planning then. This is a very real regression that
needs to be fixed.
>
> >
> > Probably the sensible thing would be for nfs-idmap to bypass the quota.
> > As keys are not held active for very long at a time, they should be garbage
> > collected in due course.
> > There is currently no interface to request this but I suspect one could be
> > added.
>
> Adding a new keyring interface might be a better question for David
> Howells, since he's done a lot of keyring work.
Let's add David to Cc then. Hi David!
>
> How many idmap keys do you have active at once? I'm guessing the quota
> is there for a reason, and increasing it in-kernel would probably be
> much easier than adding a new interface for short-lived keys.
Only 1 or 2 active at once. Lots active sequentially in a short period of
time.
The problem, as I see it, is that you are trying to use a keyring like a
cache, and it doesn't seem to be designed for that purpose.
It certainly has some of the attributes of a cache, like an LRU list and a
garbage collector. However the garbage collector doesn't discard entries
simply because they are old (as you would expect for a cache). It discards
them because they have expired or have been marked as dead.
To get the keyring to act like a cache you need some way to discard the
"oldest" when the keyring is full.
Though as the quotas are per-user rather than per-keyring I'm not sure that
is really a well defined concept.
I was imagining something like
while (request_key(&key_type_id_resolver, ...) == -EDQUOT)
discard_oldest_key(&key_type_id_resolver);
but it is entirely possible that root's entire quota is used for some other
key_type so this could fail.
David: is there some way that keyrings can be used as a simple FIFO cache
with some minimum number of entries? If not, this might require a major
redesign.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
prev parent reply other threads:[~2013-10-23 0:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-21 5:05 What is the long term fix for the idmapper key-quota problem NeilBrown
2013-10-22 14:49 ` Anna Schumaker
2013-10-22 21:30 ` NeilBrown [this message]
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=20131023083019.7dfc39f9@notabene.brown \
--to=neilb@suse.de \
--cc=bjschuma@netapp.com \
--cc=dhowells@redhat.com \
--cc=linux-nfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.