On Thu, Jan 15, 2015 at 11:26 AM, Christoph Hellwig <hch@xxxxxx> wrote: > On Wed, Jan 14, 2015 at 11:16:27AM -0800, Tom Haynes wrote: >> Christoph, >> >> I don't understand this concern. Section 8.2.1: >> >> open stateids: OPEN state for a given client ID/open-owner/filehandle triple >> >> delegation stateids: A stateid represents a single delegation held by a client for a >> particular filehandle. >> >> By definition, open/delegation stateids are tracked per >> file/client combination. > > My concern is that the language in errata 3901 says the server should > invalidate all layouts after all open stateids are closed, and all > delegation stateids are returned for a given file, which means the > server needs to add another object just to track the layouts. If > on the other hand we say the lifetime of the layouts is tied to > the open stateid or the delegation stateid used to create the > layout stateid we can track the outstanding layouts in those > open/delegation stateid (and the lock stateid as well). > The problem, in my mind, is that defeats the main purpose of return-on-close, which is to reduce the on-the-wire chattiness of the protocol. How one implements that internally on the server is not really a concern that should be reflected in the protocol. Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
