On Tue, 2010-10-19 at 08:40 +0200, Benny Halevy wrote: > 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. This would require access, directory create, and delete permissions for the directory '<mountpoint>/', which is not always a given. Besides, what if the server reboots, and my clientid changes? Trond -- 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
