Another sequence id issue

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Noveck, Dave (dave.noveck@netapp.com)
Date: 11/14/99-11:42:43 AM Z


Message-ID: <4080CE03B682D311B589009027C2286638D351@tahoe.corp.netapp.com>
From: "Noveck, Dave" <dave.noveck@netapp.com>
Subject: Another sequence id issue
Date: Sun, 14 Nov 1999 09:42:43 -0800

I came up with the following while trying to come up
with a solution for the problem of the server being 
unable to reclaim storage being used to store sequence
id's.  (In an earlier reply to Neil Brown, I had 
promised to come up with a simple solution for this,
but each time I try, it keeps eluding me).

The issue involves a client sending a request that
requires a sequence id.  How does it get it?  For
whatever object represent the lock owner, (e.g.
the proc structure), there has to be a list of 
server that the given lockowner has presented
itself to and for each a current sequence id.
So you have to search down this list and find the
associated id, increment it and send it.  If the
server we want to communicate with is not in the
list, we add it in with a sequence number of zero
and send that.

The problem is that this list has to be organized 
by server and not by mount point.  So, if we have
two mount points that the client knows about
and a given process opens files in both, the 
same sequence id stream must be used.  

So the problem is how do you determine whether
two client file systems designate the same 
server?  You can compare the IP addresses but
I believe that that isn't adquate because of
multi-homed servers, etc.  I know that we use
clientid, in part, because we can't simply allow
the server to figure out where requests are 
coming from by simply using the source IP
address.  As far as I can see, this issue is
precisely the same.  Do we need a serverid
that we can can use to see if two client mounts
are served by the same server?


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:54 AM Z CST