On Fri, Oct 14, 2011 at 4:12 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Thu, Oct 13, 2011 at 05:23:52PM -0500, Steve French wrote: >> I like Pavel's lock cleanup (1st patch of series) so far, am >> continuing to review it, but I also noticed a few things that we need >> to do in the future. This line of code: >> >> if (flock->fl_flags & FL_LEASE) >> cFYI(1, "Lease on file - not implemented yet"); >> >> reminded me that we should check if we need to implement this (in cifs >> we can return yes if we have a lease already (oplock), but in smb2.1 >> and later we can request a lease or an upgrade to an existing one, on >> the fly). > > And you'll also need to make sure you call break_lease() when you find > out it's broken. > > A description of the smb (1/2/2.1) oplock and lease semantics would be > useful--I'm curious whether they're really a good fit for the linux > vfs's lease semantics. I can probably dig up the exact references in MS-CIFS.pdf and MS-SMB2.pdf but basically SMB2 (original dialect) and CIFS have similar semantics (and Samba's need to implement CIFS oplocks drove the original implementation of leases in the kernel, although it is requested at open time via a flag, not after open as a handle based call). The problem comes in with smb2.1 which adds the ability to reaquire leases (which may be ok) and upgrade leases (from read only to readwrite) and to reuse an existing lease (so the 2nd open from the same client doesn't have to break oplock) which helps Linux which has a common cache manager. smb2.2 adds the ability to do directory leases (to cache directory entries) -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
