On Thu, 2010-10-21 at 19:50 +0200, Benny Halevy wrote: > On 2010-10-19 15:32, Trond Myklebust wrote: > > On Tue, 2010-10-19 at 08:40 +0200, Benny Halevy wrote: > >> 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 :) Yup, but you'd then need to handle both cases in order to avoid regressions. You'd also have to deal with more complex locking: avoiding deadlocks when creating mountpoint/.unlinked_while_open.<clientid> while still holding the directory mutex for the unlink(). That basically requires you to take mutexes in the opposite order to that required for a cross-directory rename. IOW: is it really worth the effort? Note also that userland can do exactly the same thing. You are basically proposing to do the whole 'trashcan' concept in kernel space... > > > > 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. 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
