[OpenAFS-win32-devel] Re: file locking

[Eric Williams]

On Wed, 20 Jul 2005, Jeffrey Altman wrote:

> A couple of points I would like to throw out.
>
> In the long term I would like to see the afsd_service.exe support both
> the IFS and SMB/CIFS interfaces at the same time.   Therefore, I would

this might require a bit more work than expected.  cm_scache_t structures
represent files to the cache manager.  there is one per fid.

the SMB version uses an smb_fid_t structure for each fid.  it contains a
pointer to the cm_scache_t.  it seems that file sharing is enforced by
flags in the cm_scache_t struct, specifically openReads, openWrites, etc.

the IFS version maintains a list of cm_scache_t's, with a single reference
(refCount = 1) to each.  they are primarily used as "backing files".
instead of an smb_fid_t per fid, there is, in the kernel, a chain of
standard IFS data structures (common_fcb_header).  sharing counts are
enforced in the kernel, using this data.

i made this decision for speed and ease of implementation.  i had
originally tried doing all logic in the afsd daemon, by shuttling requests
into userspace immediately, but this added a huge amount of overhead.  for
a simple stat, cached read, or cached write request, it seemed excessive
to have to copy that information from afsd, and not store it in the
kernel.

on the subject of cached data, the two interfaces could synchronize
themselves with an ioctl or similar when they access the same file.  is
simultaneous access a use case for the dual-interface client?

> like to see locking implemented within the cache manager.  Given the
> current demand I want to see locking available for the 1.4.1 release
> which will still not support the IFS.   The IFS will be targeted either
> at 1.6 or 2.0 or whatever comes next.

i observed lock/unlock requests to happen in large numbers when, for
instance, saving a file from an Office application.  i am interested to
see some exact counts from Asanka's work.  keeping the locking code in the
kernel provides, again, a speed advantage.  it is something to keep in
mind.

> I am in no way committed to the existing cm_Lock / cm_Unlock
> implementations.   If there is no good reason to have timed locks in the
> cache manager then we should re-write that code.   Although, it would be
> worth spending some time to understand why the timed locks were added to
> that code in the first place.   Perhaps it is due to some SMB/CIFS
> behavior that really should be implemented at SMB layer and not in the
> CM layer.
>
> I have asked Asanka Herath to develop a test application to exercise the
> various locking combinations.   We can use this application to observe
> the current behavior of the AFS Client Service via the SMB/CIFS
> interface and test the expected behavior of new code.

i immediately recognize that there are serious downsides to keeping most
of the logic in the kernel.  however, i feel that it is the best way to
leverage the close proximity to the kernel.

eric