From: Spencer Shepler (shepler@eng.sun.com)
Date: 10/18/01-08:06:08 PM Z
Date: Thu, 18 Oct 2001 20:06:08 -0500 From: Spencer Shepler <shepler@eng.sun.com> Subject: uniqueness of stateid Message-ID: <20011018200608.S100395@dhcp-aus08-227.sun.com> On Wed, Kendrick M. Smith wrote: > > 2. OPEN_CONFIRM now uses a stateid in its argument. All the other > operations which use stateids in their arguments (CLOSE, LOCK, LOCKU, > OPEN_DOWNGRADE, READ, WRITE) require the current filehandle to be > set to the object associated with the operation. Is the new OPEN_CONFIRM > also subject to this requirement? I see no reason why OPEN_CONFIRM > should be subject to this requirement, but I never saw any reason why > the other operations should be either, so I'm just asking in the > interest of consistency. I became motivated to ask this question when I > went to implement the new OPEN_CONFIRM on my server and noticed that I > couldn't use the "generic" stateid checking function called by > CLOSE, LOCK, etc. since that function checked for agreement with the > current filehandle (although it would be easy enough to add a > DONT_CHECK_FILEHANDLE flag, of course...) I will use your question to springboard a discussion about the uniqueness of stateids across the server. If the protocol were to require that stateids were unique for the entire server (across all filesystems) just like filehandles, there would be a problem with respect to filesystem migration where the server migrates the soft-state as well as the filesystem. The servers participating in the migration would have to agree prior to the migration how to construct stateids such that a collision would not occur. However, if the protocol only defines that the stateid is unique within a filesystem, this would ease the implementation burden for the migration case. This also effects what decision we make about the parameters for CB_RECALL; the arguments are currently stateid and filehandle. -- - Spencer -
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:18 AM Z CST