From: Mike Eisler (mike@eisler.com)
Date: 03/22/01-04:29:10 PM Z
Message-Id: <200103222140.NAA19918@eagle.webpros.com> Date: Thu, 22 Mar 2001 14:29:10 -0800 (PST) From: Mike Eisler <mike@eisler.com> Subject: Re: .nfsXXXX files > To this point, we have added state to the NFSv4 server but have done > it in such a way that the server is not required to store more state > than can be normally represented in the target file system. Locking > state, open state, delegation state, will be reclaimed by the client > when a server restarts. As an optimization the server can store > additional state for faster recovery. > > To remove the need for the client to rename a file to .nfsXXXX when a > client removes the file and that file is open, the server will need to > move that file to another location in the file system itself or > effectively hide it from the clients. If the server fails, the server > will now have to find and deal with these removed but accessible files > as part of its recovery procedure. This type of state recovery is a > departure from the current model and seems difficult to provide > consistently amongst a set of disparate file systems at the server. Good points. I think if a server allows an open file to be removed, and then allows that file to be accessed after the remove, then it MUST implement the capability to recover that file if the server reboots while the file is open. Conversely if it cannot recover such files, then I think it must refuse the remove, or if it allows the remove, return NFS4ERR_STALE on subsequent accesses This ought to be part of the v4.0 specification. This way, clients that test for the following, - can open files can be removed, AND - can open files be accessed after the removal, can then avoid .nfsXXXX. Maybe these tests should instead be should be attributes, but it doesn't matter to me if the attribute is added after v4.0. -mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:45 AM Z CST