[OpenAFS-win32-devel] Re: file locking

[Eric Williams]

On Wed, 20 Jul 2005, Matt Benjamin wrote:

> >> Excellent.  This is the fun part of it, I assume for IFS only?  If I
> >> understand correctly, that effectively puts IFS client and traditional
> >> client on a par wrt locking?
>
> > yes, ifs only.  the traditional client may not have functional byte-range
> > locks, but, being of the advisory type, they are not extremely useful.
>
> I think I need some help parsing that...

s/ may not / does /

they are not really on-par.  the IFS client supports mandatory locking
(barring the upcall to request a lock on the server, which is a simple
addition), while the SMB-based client supports advisory locking.


> I had written some trivial code to see what Win32 LockFile did in
> various scenarios.  Didn't attempt ones with conflicting sessions.
> Running out of AFS (recent client) on a single machine, it certainly
> appears you can lock ranges as a reader of the Win32 API docs would
> expect, but of course these don't correspond to anything in AFS.  I have
> assumed that these are IFS locks managed by windows file sharing, and
> that enforcement would also be what you would expect...  (Please correct
> here, if I have this all wrong.)

the behaviour on the SMB client that i would expect is that LockFile and
UnlockFile APIs would succeed, and would even return an indication of a
conflict properly.  however, these locks would not prevent reading/writing
to the locked regions (being advisory, after all).  asking for and
receiving a lock should also cause a RXAFS_SetLock call, which should set
a while-file advisory lock on the server.  this is my interpretation of
the code.  as jeff noted earlier, however, he was not seeing the lock on
the server-side.


> If I follow the "alternatives" discussion correctly, the issues raised
> _here_
>
> >if the cache manager were to start enforcing mandatory locks (just as a
> >scenario), there would still be problems.  mapped file (or, paging i/o)
> >requests should never be rejected because of lock conflicts.  it is
> >possible to bypass the lock on a region by using mem-mapped i/o.  this is
> >an expected and necessary behaviour; not completing such a request
> >successfully is bad.  so, if all instances have locks on them, and a
> >paging request is received, the cache manager would reject the upcall
> >read/write request.  of course, in this case, the read and write calls
> >could also be modified...
>
> could be addressed if the code responsible for doing the upcall knew
> what the RsRtl routines know about IO operations?  I'm missing how doing
> our own range reader-writer locks would address that, but, you don't
> advocate that.

we know that it would be easy to add a bypass-locks flag to the upcall
parameters.  however, this flag would likely have to propagate into the
cache manager, where the mandatory locks would actually be enforced.  if
locks were made to be mandatory, and were not implemented in the kernel,
then i would see little benefit to putting them in the rpc/upcall layer
instead of the cache manager.

> In particular, it seems to me if the FsRtl routines exist, provide a
> locking implementation for free that is likely the default implmentation
> for everyone else, too ("**Lock* 'Em Up - Byte Range Locking")*, then it
> seems the more difficult argument is for _not_ using them.
>
> Now, when you say the protocols are incompatible, it appears that the
> only issues unaccounted for are related to the time of validity in the
> cm locking interface?

that, and the idea of having keyed locks.  the keys are useful for batch
unlock operations.  they also might be used in hosted-code (such as
services sharing a process), because it helps enforce privilege.  the i/o
manager assigns the key, not the api caller.  regardless of how they are
used, they must become a part of the stored lock.

> The time-period of validity throws me--seems to be a Windows CM-ism?  I
> didn't run into this in afs_lockctl, nor do I see it in afs.h,
> afsint.xg, and so forth.

i can't speak to this, but i believe jeff has addressed it.  briefly
reading the client code, it seems to assume that the server is timing out
the lock.

> >a simpler solution is to use the kernel's FsRtl functions to manage locks,
> >and to send the whole-file-lock request up to a daemon which spins on
> >making lock requests as often as necessary (because of expiry).  this is
> >similar to smb_WaitingLocksDaemon.  even if the lock is dropped by the cm,
> >for one of any number of reasons, the mandatory lock is still enforced
> >correctly in the kernel.  this is what i would like to do.
>
> Aside from the the lock expiry "spinning" behavior, the solution you
> propose does sound to me like the analog of the behavior I implemented,
> Nathan Neulinger described, etc.
>
> Would we need a lock-re-upping daemon if the Windows CM worked like the
> Unix cms in this regard?

can locks be broken by the server, and is the client notified?

eric