kernel support for open share modes

[William A.(Andy) Adamson]

mba2000 at ioplex.com said:
> Tim Potter said:
> I am pretty sure that under Linux there is coordination within the
> kernel between NFS locks and SMB oplocks so that there can be no data
> corruption.  Take a look at the various locktest programs in the
> (samba3) torture testsuite.
> Yes, with oplocks I know Linux and BSD have ioctrls or whatever specificly
> doing SMB oplocks. But between the time Samba opens the file and grabs the
> lock the NFS server could swoop in and grab the lock first. Or delete the
> file. Combine that the access checks necessary to determine if it should
> proceed (e.g. to send an oplock break) and you have quite a few places where
> if one operation fails (e.g. because an NFS client swooped in and did
> something) you have some serious ping-ponging and backtracking to do. I can't
> think of a concrete example off the top of my head but I'm pretty sure there
> are scenarios where a race just outright breaks proper semantics. However
> again, this level of coordination between Samba and external programs is
> pretty rare. I'm just saying technically the only way to make it truely
> correct is to wrap the whole open sequence in a shared lock.

the NFSv4 server uses the same struct file_lock F_LEASE code that samba uses 
(via fcntl_set/getlease) to implement delegations. so samba op_locks, NFSv4 
delegations are coordinated, and local access are all coordinated. from the 
NFSv4 delegation view point, there are no races because handing out a 
delegation is optional - decided by the server.

OPEN share deny modes are not implemented for local file access (e.g. not part 
of the POSIX interface). the NFSv4 server currently bookeeps deny shares in 
it's memory - there is no attempt to coordinate with local access, or samba. 
indeed, since share mode checks are an atomic part of an OPEN call, it's 
difficult (if not impossible) to implement deny shares as an aside to OPEN.  
unless a non-POSIX OPEN syscall with deny share bits is made availible (which 
i don't expect to happen), we have to live with partial non-coordinated/racy 
solutions. we propose an open with deny bits as a new struct export_operations 
function so that multiple NFSv4 servers can export symetric cluster file 
systems. the new call will allow the symetric cluster file system to bookkeep 
deny shares on behalf of the NFSv4 server, allowing coordination between the 
multiple NFSv4 servers exporting the same back end FS. this will not provide 
coordination with local access, nor with samba.....

-->Andy