On 2010-10-18 19:10, J. Bruce Fields wrote: > 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 The clients can do something similar too, like sillyrenaming the files onto <mountpoint>/.unlinked_while_opened.<client-id> Removing this directory when it empties. Benny > 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 -- 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
