All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Steve Dickson <steved@redhat.com>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 3/3] gssd: base the size of the fd array on the RLIMIT_NOFILE limit.
Date: Thu, 29 Nov 2012 11:30:51 +1100	[thread overview]
Message-ID: <20121129113051.046bc658@notabene.brown> (raw)
In-Reply-To: <20121128131054.GB11651@fieldses.org>

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

On Wed, 28 Nov 2012 08:10:55 -0500 "J. Bruce Fields" <bfields@fieldses.org>
wrote:

> On Wed, Nov 28, 2012 at 12:11:23PM +1100, Neil Brown wrote:
> > We have previously raised the size of the 'pollarray' once (32 -> 256)
> > and I have had another request to make it bigger.
> > Rather than changing the hard-coded value, make it depend on
> > RLIMIT_NOFILE.  This is an upper limit on the size of the array
> > that can be passed to poll() anyway.
> 
> Sounds like a good idea.
> 
> Just out of curiosity: how does it fail?  I guess mounts just start
> failing at some point--how do people find the workaround?

Error seems to be

rpcsec_gss: gss_init_sec_context: (major) Miscellaneous failure - (minor) Cannot contact any KDC for requested realm

in rpc.gssd logs.

I guess people could read the source to find the work around .... not ideal
though.  I guess we should get gssd to generate some more helpful message.

The seem to be further problems that the customer is experiencing so I might
wait until they are completely resolved to ensure I have complete
understanding before I propose a further patch.

NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2012-11-29  0:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-28  1:11 [PATCH 0/3] Make size of gssd_proc fd array a little more dynamic Neil Brown
2012-11-28  1:11 ` [PATCH 2/3] gssd_proc: remove pointless test against FD_ALLOC_BLOCK in process_pipedir Neil Brown
2012-11-28  1:11 ` [PATCH 1/3] gssd_proc: use pollsize, not FD_ALLOC_BLOCK, in get_poll_index() Neil Brown
2012-11-28  1:11 ` [PATCH 3/3] gssd: base the size of the fd array on the RLIMIT_NOFILE limit Neil Brown
2012-11-28 13:10   ` J. Bruce Fields
2012-11-29  0:30     ` NeilBrown [this message]
2012-12-11  0:02       ` NeilBrown
2012-12-11 16:16         ` J. Bruce Fields
2012-12-13  6:03           ` NeilBrown
2012-12-13 19:21             ` J. Bruce Fields
2012-11-28 19:54 ` [PATCH 0/3] Make size of gssd_proc fd array a little more dynamic Steve Dickson

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=20121129113051.046bc658@notabene.brown \
    --to=neilb@suse.de \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=steved@redhat.com \
    /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.