Subject: nfs_lockowner structures on server

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 21 Oct 1999 18:48:39 -0700

I think there is a problem with the management of whatever structures the
server uses to keep track of nfs_lockowner's.  I don't see how the server
can ever get rid of them until the client reboots.  The memory required might
grow without bound.

I assume that you would have to keep a structure for each nfs_lockowner
that contained, the client id, the opaque owner information and the 
sequence id associated with that lockowner.  Such a structure would have
to be findable from the combination of client-id and opaque owner information
(probably using a hash).  You could have whatever structure represented 
stateid's on the server point to this lockowner object, but the reason you
absolutely need to have a separate lcokowner structure is that you need
to keep the sequence id.  I think you have to keep that sequence id, and
thus the enclosing structure even when that lockowner owns no locks
at all.  Is there some way, that I am missing, for the server ever to get
rid of it?  Client might reasonably not want to recycle the opaque owner 
id's since doing so would mean that would have to keep track of sequence
id's for owners that didn't really exist, so I assume that they would try
to make them unique throughout a client's life.  If the server were stuck
with one such for every lock-owner he ever saw, memory would fill
up with uncollectable (even for Brent's server) garbage.  Is there some
mechanism I'm missing that allows this space to be reclaimed?