On Mon, Oct 18, 2010 at 11:01:38AM -0400, Jeff Layton wrote: > On Mon, 18 Oct 2010 15:53:44 +0100 > ClÃudio Martins <ctpm@xxxxxxxxxx> wrote: > > > > > On Mon, 18 Oct 2010 15:48:11 +0100 ClÃudio Martins <ctpm@xxxxxxxxxx> wrote: > > > > > > Section D2 ends with: > > > > > > "The NFS version 4 protocol is stateful, and could actually support > > > delete-on-last-close. Unfortunately there isn't an easy way to do this > > > and remain backwards-compatible with version 2 and 3 accessors." > > > > > > So, theoretically, could one modify the code to selectively disable > > > silly rename on a client, when it knows it is talking v4 with the > > > server? > > > > > > > BTW, to clarify, I'm assuming a scenario where the server is > > configured to talk v4 only, which I suspect should be common, at least > > when you're relying on v4 kerberos security. > > > > Sadly, no... > > The server does generally hold the file open as long as the client has > the file open. So, you could delete the file while nfsd has it open and > everything would probably still work. > > Suppose though that the server crashes and reboots. When it comes back > up, fsck figures out that the file has been unlinked and frees the > blocks on the disk. Now you can't reclaim the state on the open file. > > We're pretty much stuck with silly-renaming even for v4. The server could do something like rename the file into a special directory somewhere that only it had access to, preserving the file across reboot. Then at the end of the grace period it would remove any files in that directory that had not been reclaimed by some client. The problem would still remain that the *client* wouldn't know that the server was capable of doing this, so would still be stuck doing sillyrename on its own just to be sure. NFSv4.1 adds an open return flag which allows the server to tell the client that the client doesn't need to do sillyrename; see the discussion of OPEN4_RESULT_PRESERVE_UNLINKED flag in rfc 5661. I don't think anyone's looked into implementing that yet; might be a fun project. --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
