From: Noveck, Dave (dave.noveck@netapp.com)
Date: 09/27/99-09:14:47 AM Z
Message-ID: <7F608EC0BDE6D111B53A00805FA7F7DA05D10C51@TAHOE> From: "Noveck, Dave" <dave.noveck@netapp.com> Subject: RE: recovery from NFS4ERR_FHEXPIRED Date: Mon, 27 Sep 1999 07:14:47 -0700 > This is a good answer. It follows the client-side > implementations need to be prepared for NFS4ERR_GRACE > from all ops, not just OPEN or LOCK. I'm not sure about *all* ops. Should it be valid to return NFS4ERR_GRACE for PUTFH or SETCLIENTID, for example? The list should be definitely expanded. It's not clear whether we just have a small set for which NFS4ERR_GRACE is allowed (OPEN, LOCK, REMOVE, RENAME) or allow it for everything except some other set of exceptions. > > Is it safe to say the pathname is the only > possible recovery for volatile file handles? > Only repeated LOOKUPs and OPENs can recover > expired handles? I believe so. Comments? > > The NFSv4 spec should at least *RECOMMEND* > that servers which return volatile file handles > defend the file name space and also use > the trans-reboot grace period as Carl > described. The spec should also *REQUIRE* > client implementations to handle NFS4ERR_GRACE > for all operations. The client should certainly be required to handle anything that we recommend that servers do. > A set of *RECOMMENDED* > heuristics for the client-side to defend > file content would also be a good topic > for the spec, but since file identity is > problematic, such heuristics should not be > required of either the client nor server. If a server is going to take an open file and all of a sudden connect it to a different object then I'm not sure what heuristics a client could use to defend it's files other than to not use such a server. > > The whole mechanism begs the question of a lost > CLOSE. There are similar issues for client-side > caching, and I would urge that the same > mechanism be used in this case. I'm confused. What mechanism begs what question regarding a lost CLOSE? What are the similar issues for client-side caching and what mechanism needs to be used in that case? > > OBTW, SMB ain't got a solution for the > client/client trans-reboot race condition. > Chalk one up for NFSv4. I love it when > that happens. Nice going, Carl. >
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:39 AM Z CST