kernel support for open share modes

[William A.(Andy) Adamson]

mba2000 at ioplex.com said:
>  I believe it's generally accepted that there are certain incompatibilities
> and limitations between the protocols and the POSIX APIs that prevent proper
> coordination for many operations. POSIX simply isn't sophisticated enough to
> implement a full featured userspace network filesystem in a way that can
> communicate consistent systemwide state. POSIX was designed to be simple (I
> guess because it's more secure).

> The only possible way to make opening and setting additional file attributes
> (e.g. deny modes) atomic is to perform both operations under a lock that is
> respected by all parties involved. Locking within userspace memory is
> sufficient for all clients of that application. But enties outside of that
> application will, by default, have no knowledge of the special locking and
> therefore it is simply not possible to coordinate them properly.

> The only truely correct solution that can coordinate all entities systemwide
> would require that code within the OS kernel be used to control all access
> checks and set additional attributes atomically as necessary. For Linux that
> might actually be reasonable thing to do but note that in this instance it
> would be necessary to change the behavior of the general file locking code as
> opposed to simply adding some VFS hooks with a loadable module.

> In practice it is not terribly common for an application to require this
> level of corrdination however. It is usually simpler to simply force the
> external application to be a client of the appliction maintianing the locks
> as opposed to being a client of the local system. Meaning, make your app do
> all filesystem I/O through Samba.


bfields at fieldses.org said:
> The application in question is the kernel NFS daemon, which is *not* going to
> do all its filesystem I/O through Samba....

we are considering providing the kernel NFSv4 daemon with a file system 
interface for OPEN that could be used instead of the POSIX struct 
file_operations->open and which would include deny share bits. since struct 
file_operations == POSIX operations, we are thinking of adding this special 
non-POSIX open to the export_operations.

the need for this new open is driven by 1)cluster file systems (GFS, GPFS, 
Polyserve, etc) that desire to be exported by mulitple NFSv4 servers, and 2) 
the design point of using the cluster filesystem to bookeep share 
[access,deny] as opposed to using NFSv4 memory and having an NFSv4 server to 
server protocol.

the underlying file system should allow a local OPEN through the POSIX 
interface on a file that has been opened with conflicting deny access by the 
NFSv4 server, respecting the deny access only WRT OPENs via the new 
interface....

-->Andy