Re: New client-side locking implementation

On Tue, 26 Jul 2005, Jeffrey Altman wrote:

> Matt Benjamin wrote:
> > 1. Does something need to be said about the choice to enforce mandatory
> > locking?
>
> As opposed to the other choice which is to *NOT* enforce mandatory locks?

another choice is to enforce locking in an advisory manner (advisory
locking).

> Windows applications rely on the mandatory locking model of Windows file
> systems.   If we do not enforce the mandatory locking model, then there
> is no benefit to doing this work at all.  A cache manager that loses a
> lock and then continues to allow applications to access the file as if
> the lock is in place might as well overwrite the file with the output
> of /dev/random since those will be the resulting semantics.
>
> There was an interesting set of discussions on the subject of mandatory
> vs advisory locking on the nfsv4 wg mailing list.   The conclusion was
> that mandatory locking must be enforced for Windows applications and
> Posix implementations which require data integrity.
>
> > 2. This will allow byte-range locking to work within the traditional
> > cache manager.  In the IFS context, it is common to use kernel locking
> > implementation, and Eric had planned to do so.  Should this doc specify
> > how an IFS should interact with the CM wrt locks?
>
> In previous discussions, Eric has pointed out that his existing
> implementation enforces locks by calling cm_Lock()/cm_Unlock().   The
> use of this model will be necessary whenever afsd_service.exe is
> supporting both the CIFS/SMB and IFS interfaces simultaneously.   In the
> circumstance in which only the IFS is being used, kernel locking can be
> used.

the code in place currently does not call cm_Lock/cm_Unlock.  i simply
pointed out that the fns were available and could be called through the
existing upcall mechanism.  the current code does, however, use the
kernel-provided FsRtl locking library, which works well.

the FsRtl library has two hooks for lock operations.  when a lock is
placed, the hook is then called and has veto power.  when a lock is
removed, the second hook is called.  these are meant specifically for
network redirector use.  given the semantics discussed, calling
cm_Lock/cm_Unlock from these hooks seems to be a good solution.  in this
manner, the IFS interface does not have to be aware of CIFS-based
operations.

> The interface to cm_Lock()/cm_Unlock will change in order to support
> the notion of keyed locks.
>
> > 3. Sense need to ask questions about the key mapping, and relation to
> > keys known to IFS.  Eric would have to comment, though, I'm not
> > knowledeable enough on that.

IFS depends on locks being set on FileObjects (the kernel result of an
IRP_MJ_CREATE request), and being enforced on the entire file.  this only
matters because of unlock_all and unlock_by_key requests, which apply to
the specified FileObject, and not to all open instances of the file.

in fact, it would be possible to use a KeyA = Key(FileObject).  the
FileObject is unique -- across processes, users, files.  making KeyA
dependent on processID, as i had earlier proposed, is redundant.

> A key must consist of the SessionID, the ProcessID, and the FID in order
> to provide uniqueness both for the file and the user.   The SessionID is
>  irrelevant for the IFS because the ProcessID name space is unique.
> Therefore, for the IFS the SessionID can be set to a fixed arbitrary
> value that will not be used by the CIFS/SMB interface.

if the list of locks is stored in a queue attached to the cm_scache_t,
then i do not see why there exists a dependence on the FID.

>
> Jeffrey Altman
>

eric