Re: New client-side locking implementation

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?

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 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.

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.

Jeffrey Altman

begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:Secure Endpoints Inc.
adr:;;255 W 94TH ST PHB;NEW YORK;NY;10025;United States
email;internet:[email protected]
title:President
tel;work:+1 212 769-9018
x-mozilla-html:TRUE
url:http://www.secure-endpoints.com
version:2.1
end:vcard