From: Brent (brent@eng.sun.com)
Date: 05/10/99-12:02:31 AM Z
Message-ID: <37366867.6675EE73@eng.sun.com> Date: Sun, 09 May 1999 22:02:31 -0700 From: Brent <brent@eng.sun.com> Subject: Re: File Handle definitions-behaviors (version 2) I think Spencer's table is great for discussing boundary properties of volatile filehandles, and Dave's suggestion for its application to testing is good. I do hope we can summarize the properties of filehandle volatility in just a paragraph or two in the final spec. I don't think it really deserves any more than that. Non-volatile filehandles assumed a very tight binding of the filehandle to almost a disk address. A volatile filehandle is a looser binding perhaps to a pathname. Of course, non-volatile is better if your server can implement it. If not, then volatile is a second-best and entails some risk. When a server gets a non-volatile filehandle and returns a STALE error, it means that the file is gone, kaput, When a server gets a volatile filehandle and returns an EXPIRED error, it means that the filehandle binding is broken, but the file might still be around. The client can attempt a fix if it dares, e.g. re-evaluate the pathname. I understand Dave's concern that a pathname re-evaluation might take the client to a different file because of an undetected rename. That would be very bad, and it needs a big caveat. The "loud" errors are bad enough, but "silent" errors like data corruption are much worse. My recommendation would be that the spec have a simple, clear definition of filehandle volatility - followed by a short discussion of the recovery implications. Brent
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:00 AM Z CST