Subject: two questions on new .x

From: "Kendrick M. Smith" <[email-masked]>
Date: Wed, 17 Oct 2001 13:49:19 -0400 (EDT)

1. The new OPEN_CONFIRM uses a stateid as its argument instead of a
verifier.  However, the OPEN response still includes the verifier,
which is no longer used anywhere.

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...)

- k

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 18 Oct 2001 19:49:35 -0500

> which is no longer used anywhere.

This was my oversite.  The verifier is now moot as you point out.
When should this be changed in the .x?  Anyone have an opinion?

-- 

- Spencer -

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 18 Oct 2001 20:06:08 -0500

> 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 -