From: David Robinson (David.Robinson@Sun.COM)
Date: 01/31/02-10:35:37 AM Z
Message-Id: <200201311635.g0VGZba27824@phys-hanwk16-1.ebay.sun.com> Date: Thu, 31 Jan 2002 10:35:37 -0600 (CST) From: David Robinson <David.Robinson@Sun.COM> Subject: Re: initial delegation experience > 1. Suppose that client A has a delegation on a file, and the server > receives a REMOVE, RENAME, or SETATTR request from client B on the same > file. If A != B, the server must recall the delegation. If A == B, it > would be nice if the server could handle the request without recalling > the delegation. As the protocol stands, this is impossible: the server > has no way of knowing if the request really came from client A, or if > it came from a different client tunelling through the same NAT box as A. > One solution to this problem would be to add a clientid to REMOVE, RENAME, > and SETATTR (note that truncating SETATTR's contain a stateid, so the > clientid can be inferred, but non-truncating SETATTR's do not). I see this as the client getting what it asked for. The semantics are clear on when the delegation is recalled by the server, if the client decides to issue a request back through to the server that will cause a recall then it gets what it asked for. A smart client that has the delegation will delay the request until either the server recalls the delegation or the client is willing to give it up. It means the client needs to maintain more state about operations that need to be completed and of course makes interesting recovery issues, but then all of delegation has that property. > 3. This last one isn't really an implementation issue, more of a > question. One central requirement of the NFSv4 protocol design process has > been the requirement that a LOCK/LOCKU operation change the file's > stateid, so that replayed WRITE's are "locked out" and return > ERR_OLD_STATEID. In this way, LOCK/LOCKU acts as a serialization point > for WRITE requests. In fact, most of the complexity of the NFSv4 state > model can be attributed to this requirement, including the recent .x > changes. > > The plot thickens, however, with sec. 9.4.2 of RFC 3010 in the picture. > According to this section, a client which holds a delegation is supposed > to perform its locking operations locally. If such a client performs > interleaved locking and WRITE operations, the locking operations will > be performed locally but the WRITEs will eventually be flushed to the > server. From the server's point of view, the client is only sending > WRITE's, with no LOCK/LOCKU's to update the stateid. The serialization > properties of LOCK/LOCKU are lost when a delegation is held. > > So, my question is, should the client really do as sec. 9.4.2 advocates, > and perform its locking operations locally? In other words, which is > more valuable: > (a) The potential performance advantages of performing locking > operations locally whenever a delegation is held > (b) The design requirement that LOCK/LOCKU act as a serialization point > for WRITE requests? But there is serialization, it is just now occuring at the granularity of the delegation and not the LOCK/LOCKU. Serialization is important for two reasons, creating consistent state between two clients and protection against replays corrupting state. With a delegation the former can't occur because any other client attempting an operation will cause the delegation to be removed. If that occurs the client will flush the pending writes as well as the current lock state. From the server's perspective it just sees the consolidated set of requests. Locally the client provides synchronization within its buffers and the lock requests to replays are not an issue. I have not checked the latest draft, but the only implication here is that the stateid MUST change when a delegation is given or recalled in order as the delegation is the course grained synchronization. This is needed no only to handled the case where the client has performed locking but to also keep a replay from causing a recall or invalidating the clients cached data. -David
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:29 AM Z CST