Subject: Spec-related discussions at the Bake-off

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 1 Nov 2000 08:34:17 -0800

As well as doing a lot of inter-operability testing, the 
assembled developers had many discussions about things
in the spec that were either unclear or seemed wrong or
troublesome to impleement.

We listed these items on a big whiteboard (two-sided and
we did overflow to the other side).  I've reproduced 
those items together with my best attempt to summarize 
the discussion in the attached html file.

It's been suggested that we put the html file somewhere
on nfsv4.org.  Can someone do that?

---

From: David Robinson <[email-masked]>
Date: Thu, 02 Nov 2000 18:32:33 -0800

A few comments although I have not been very active as of late.

> 1b) Need for sequence synchronization op
> 
> In view of a number of problems in which client and server got their sequence id's out of sync, there was some
> discussion about whether we need a new op to synchronize sequence id's for a particular lockowner. Without that,
> there's really no way to recover. 
> 
> The consensus was that we would see if the clarifications made regarding sequence updating would suffice to make this
> problem go away. Until we have more experience, we shouldn't pursue additional op's to deal with this problem. 

This is a bad idea, like allowing "ch = *(NULL);" to work, fix the bugs
not the protocol.

> 1c) Remembrance of state-id's past
> 
> During the discussion of item 1, Dave brought up the issue of a retransmitted CLOSE. To respond correctly, it is
> necessary to compare the sequence id to the sequence id for the lockowner. This necessitates knowing the lockowner.
> The problem is that the lockowner can only be found using the stateid passed in the CLOSE. If the CLOSE
> succeeded, then you would expect the state entry to be deallocated, which means that you would get a
> BAD_STATEID error and the server will be unable to find the lockowner necessary to treat this as a duplicate. 
> 
> Dave talked about this could be dealt with in the server implementation by delaying the deallocation of state entries,
> until it was determined that they would not be needed to resolve duplicates. This description also appeared in a
> message to the working group. (A link to the archives should be here but this message doesn't seem to be in the
> archives). 
> 
> Carl Beame found Dave's solution to complicated and suggested instead that the server be allowed instead to treat a
> CLOSE with a BAD stateid as a no-op and allow the server to return OK in this case. 

To handle retransmission of CLOSEs it was always my view that the server
has to maintain a small amount of state until it is sure there is no
retransmission.  It is reasonable to make this a lease interval
returning
the previous response, after which treat it as an error.

> 4) Lease and deadlocks
> 
> There was some concerns expressed about leases in a situation in which a given lockowner obtained a lock and then
> hung. If other processes continued unaffected then the leases associated with the locks held by the lockowner would be
> periodically renewed, even when, it could be argued, they shouldn't be. 
> 
> The general consensus was that this behavior was inherent in the lease design and that it was the responsibility of the
> client operating system to deal with, but perhaps the spec should discuss this issue. 
> 
> Carl Beame suggested that the spec encourage servers to provide some sort of facilities for administrators to cause
> locks to be revoked. Currently, the spec does make passing reference to administrative revocation of locks where
> leases have not expired. Perhaps the text here could be strengthened a bit. 

Lease are NOT per file, they are simply a mechanism to ensure that the
client
and server maintain a consistent view of the state. If a lockowner is
not
responding it is up the the client operating system/application to
cleanup
the state.  The tool that Carl suggests is not a bad idea, Solaris has a
clean_locks utility to free dead NLM locks by an administrator.

> 15) NT server issues with OPEN upgrade
> 
> The Hummingbird people have come up with an issue regarding the open upgrade-downgrade model that is currently in
> the spec. There is no easy method whereby an NT server might implement a downgrade request in general. NT does
> not provide the requisite semantics. 
> 
> It might implement this by handling the open upgrade by doing a second open and then closing one of its open's when a
> downgrade is done. There are some problems with this. As the spec stands, the client is not constrained in precisely
> what downgrades it would do, making it possible for it to make requests, that cannot be handled by the server closing
> one of its opens. Even if this could be resolved, there remains an issue with byte-range locks. The NT server has no
> way of knowing which of his opens to assign the locks to. He might assign them to an open which needs to be closed
> to satisfy a subsequent downgrade. 
> 
> Carl Beame asks why upgrade-downgrade is done that way, instead of allowing multiple opens each of which results in
> a separate stateid that might be independently closed. Nobody had an answer. The archives need to be checked to see
> what the reason was. 
> 
> There was considerable discussion of this issue. The consensus was that it needs to be resolved somehow, but nobody
> was ready to decide on anything yet. Andy expressed worry that allowing multiple OPEN's for a given file-lockowner
> pair would increase server memory requirements. More discussion of this issue on the working group alias is required.
> Dave will comb the archives and summarize the history of our current solution to upgrade-downgrade and what
> problems have been cited about other proposed solutions. 

I don't recall what the motivation for an upgrade/downgrade OPEN was.
I don't believe that any existing APIs that handle shares has this
capability so I question why it shouldn't just be done with a CLOSE
followed by an OPEN, if it is ever needed.

> 18) Unlimited-length opaques. Just say "No"?
> 
> Andy points out that there are a number of unlimited-length opaques in the protocol (e.g. client-string, lockowner) and
> that each each such adds to server vulnerabilities to denial-of-service attacks. The possibility of a 32 kbyte lockowners
> appearing makes coding of the server more complicated and will hurt performance in the normal case, unless great
> efforts are made to optimize server performance. 
> 
> Scrubbing the .x file for unlimited-length opaques and providing liberal bounds for each seems like a good idea.
> Although it is not impossible that future developments will require us to breach limits that seem quite liberal right now,
> we have the minor versioning mechanism to deal with this possibility. Making things unlimited length has a cost in
> complexity, performance, and stability, that we probably don't want to pay. 
> 
> Andy has graciously volunteered to go through the spec and come up with a proposal on the limits that need to be
> added. 

I disagree with this one.  With existing NFSv3's variable length
structures
we already check for sane values in our implementation.  Why have the
protocol limit values? If a server gets values too big just return
a decode error. We do that today (after discovering it the hard way :-)

	-David

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 3 Nov 2000 15:03:57 -0600

> 
> 3) Multi-component pathname issues
> 
> A number of proposals were made to more accurately report errors that
> occur in handling multi-component pathnames for OPEN and LOOKUP. The
> difficulties in recovering from a situation in which one of the
> directories in a multi-component path name turned out to be a symlink
> were discussed, with much gnashing of teeth.
> 
> The consensus was that these difficulties make use of multi-component
> pathnames undesirable with a better alternative being COMPOUNDed
> LOOKUP's. This makes it desirable to remove multi-component pathnames
> from OPEN and LOOKU

The issue of recovering from an error with the use of a pathname4 on
OPEN and LOOKUP is one that the client needs to deal with.  The server
processing should be straightforward.

Therefore, if the client doesn't want to deal with the error recovery
it doesn't need to generate an OPEN or LOOKUP with a multi-component
pathname4.  It can generate the appropriate COMPOUND.  If the client
is smart enough to deal with the error recovery, then it has the
option.

I don't see a need for any change.

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 3 Nov 2000 15:15:34 -0600

> 
> 13) Attributes needed on create
> 
> Sergei has problems with the fact that you cannot specify attributes
> when doing a CREATE, in the case of creating a directory, for
> example. The option of doing a SETATTR after the create may not be
> available in some cases, as when you want to set the owner, since
> servers will often not let you change the owner unless you are the
> owner or root.
> 
> The consensus was that CREATE needs to be enhanced to allow attributes
> to be specified for all non-regular file types.
> 

So there are server environments that will create directory whose
owner is different than those specified in the credentials of the RPC
call?  I am assuming that the client is not specifying the owner on
the create.

Most servers require the credentials to have some type of privilege to
change the owner of an object to something other than the current
owner of the object.

I don't see the issue here.  The object will be created with the
default owner as specified in the RPC credential and that user will
then have the appropriate authentication to set attributes for the
object.

-- 

- Spencer -