On Wed, Sep 21, 2011 at 11:02:41AM -0400, Christoph Hellwig wrote: > On Wed, Sep 21, 2011 at 10:58:14AM -0400, J. Bruce Fields wrote: > > A read lease is used by NFSv4 as a guarantee that a client can perform > > local read opens without informing the server. > > > > The open operation takes the last component of the pathname as an > > argument, thus is also a lookup operation, and giving the client the > > above guarantee means informing the client before we allow anything that > > would change the set of names pointing to the inode. > > That seems like totally strange semantics. A useful defintion of a > lase operation would mean it guarantees I/O can happen, and wouldn't > care about metadata operation. That's the whole point in adding a > stateful open to nfs4, isn't it? One of the purposes of a delegation (==lease) is to let clients perform open() entirely locally, without waiting for any round trips to the server. That doesn't work if the client has to revalidate the open path on every open(). (And as I understand it--Trond can correct me if I'm confused--revalidating at least the last component of the path is a requirement for the close-to-open semantics that the Linux client guarantees to applications.) I dunno, perhaps a more logical way to do that would be to define some kind of lease on the parent directories. That's not the way the protocols work. --b. -- 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
