From: Peter Skensved <peter@jay.phy.QueensU.CA>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: nfsd4_stateowners problem
Date: Tue, 14 Sep 2010 16:24:06 -0400 [thread overview]
Message-ID: <20100914202406.GA8880@jay.phy.QueensU.CA> (raw)
In-Reply-To: <20100914200054.GC4148@fieldses.org>
On Tue, Sep 14, 2010 at 04:00:54PM -0400, J. Bruce Fields wrote:
> On Tue, Sep 14, 2010 at 02:40:44PM -0400, Peter Skensved wrote:
> > Thanks for the reply. The current RedHat EL5 kernels are all based on 2.6.18 with
> > a lot of backported fixes so I'm not sure what version of the NFS code I'm effectively
> > running.
> >
> > Do you know what the state_owners are used for ? What puzzles me is that in our case
>
> They represent some notion of "who" is performing an open, or performing
> a lock.
>
> > we have a large number of workstations which NFS mounts some fairly large, mostly static
> > common directories and automounts HOME directories. So I would expect the amount of state
> > info that needs to be kept would be fairly constant. When the automounter unmounts the
> > info ought to go away . Yet the number of stateowners for the most part just keep on
> > growing.
> >
> > The only work around at the moment is to reboot before it has eaten up around 500 Mb
> > of slabs
>
> Is someone doing a lot of file locking?
Not that I'm aware of -
>
> I can't remember the logic the server uses to decide when to throw away
> a lockowner, but it may just be inadequate.
>
> The client has also had some fixes recently to be better about telling
> the server when to throw them away.
>
> --b.
prev parent reply other threads:[~2010-09-14 20:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-27 17:48 nfsd4_stateowners problem Peter Skensved
2010-09-14 17:31 ` J. Bruce Fields
2010-09-14 18:40 ` Peter Skensved
2010-09-14 20:00 ` J. Bruce Fields
2010-09-14 20:24 ` Peter Skensved [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=20100914202406.GA8880@jay.phy.QueensU.CA \
--to=peter@jay.phy.queensu.ca \
--cc=bfields@fieldses.org \
--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.