Re: [PATCH] VFS: Unlink should revoke all outstanding leases on file

[Jamie Lokier <jamie-yetKDKU6eevNLxjTenLetw@public.gmane.org>]

J. Bruce Fields wrote:
> On Fri, May 14, 2010 at 11:16:43AM -0700, Jeremy Allison wrote:
> > On Fri, May 14, 2010 at 06:46:53PM +0100, Jamie Lokier wrote:
> > 
> > > I think you can delete open files on Windows nowadays, if they are
> > > opened with a particular flag.
> > 
> > You can only mark them as "to be deleted" once the last opener
> > closes. They still exist in the namespace.
> 
> So, I'm a little lost: in your opinion, would leases be more useful to
> Samba if they were broken on delete, or if they weren't, or does it not
> matter because you'll never do that?

Samba might not delete open files (I'm not sure), but the Linux user
on the server can still unlink the files, or rename over them.

What should happen then, I'm not sure.  Maybe Samba should be able to
delay the delete (like reads/writes can be delayed), or maybe it
should be able to refuse the delete altogether (similar to the way
the fanotify framework can block operations).

> I see three options:
> 	1. modify the existing file lease behavior to match what NFSv4
> 	   (and Samba?) needs; or
> 	2. leave the existing leases alone and create some new lock type
> 	   (or otherwise flag some leases somehow) that does what we
> 	   want; and, if we do that, either:
> 		2a. leave the new leases in-kernel-only, or
> 		2b. expose the new leases to userspace somehow so Samba
> 		   (or whever) can use them.
> 
> I don't think any of 1, 2a, or 2b is likely to be harder than any other,
> so it's just a question of what we want.

I think changing the userspace contract for long-standing F_SETLEASE
is rude at least.  Samba and NFS aren't the only lease users, and
anyway people will still run old Samba on new kernels; changing its
behaviour is a bit risky.

Imho, new lease semantics should use new userspace API.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html