Re: Re: file locking

Eric Williams wrote:

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

unfortunately, I don't think there is any code whatsoever that actually
utilizes the openReads and openWrites fields in the struct.

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

preferrably yes but it does not necessarily have to be that way.
I can see arguments for both.

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

keeping locks in the kernel is certainly a performance benefit if we
know for sure that only one mode can be in use at a time.

However, even if the locks are maintained in the kernel for the IFS
case, we will still need equivalent code in the CM for the SMB/CIFS
interface.

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