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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox