Re: New client-side locking implementation

On Fri, 29 Jul 2005, Jeffrey Altman wrote:

> Eric Williams wrote:
>
> > 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.
>
> Eric:
>
> I wanted to come back to this portion of the thread for a few minutes.
> Given that the Windows locking model is "mandatory", do you have a
> proposal for how "advisory locking" could be used while still
> maintaining data integrity?
>
> Jeffrey Altman

mandatory locking seems to be very useful for accessing a file with 'k'
permissions.  obviously, this is not always the case.  it seems reasonable
to me that a user with the 'w' permission flag should be able to save an
office document into an AFS share.

so, i see a trade-off between client usefulness and data integrity.  if,
for instance, the SetLock rpc fails (due to permissions), we could enforce
advisory locking across processes on the same machine.

i don't propose this to make things complicated.  i believe a typical
use-case is to work on an office document that resides in AFS.  the
application opens/reads/closes the file; the user works with it; and the
application opens/locks/writes/closes it.  if the lock cannot be obtained
on the file, it should be clear the file is in use on another client;
however, if the lock is never obtainable (not allowed), then it is
unlikely the file is in use, and it would be a great benefit to be able to
save it.  the client could check the server for locks, and, finding none,
allow advisory locking.

perhaps i am trying to make the client too useful.  in this scenario,
there are ways to lose data, of course.

eric