On 2010-10-19 15:32, Trond Myklebust wrote: > 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. Correct. But that's pretty easy to probe :) > > Besides, what if the server reboots, and my clientid changes? By <client-id> I meant a unique identifier for the client, not necessarily the nfsv4.x clientid. The client could just as well use its ip address (to help admins deal with the aftermath in case the client goes away) and its boot time, or even a random string. Benny > > 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
