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. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
