[AFS3-std] File Server/Cache Manager Extended Status Information

[Jeffrey Hutzelman]

--On Sunday, April 06, 2008 05:39:09 PM -0400 Jeffrey Altman 
<jaltman@secure-endpoints.com> wrote:

> Why should the client have to request an extended callback notification?
>
> The client already sends the file server a capabilities list as part of
> the
> TellMeAboutYourself response.  If the client supports the extended
> callbacks it can notify the file server in the TellMeAboutYourself
> response
> and the file server can simply send the extended callbacks.

Agree.  Clients should not have to do anything to receive extended 
notifications other than advertise support for them.


> I do not understand this level of complexity.  A callback is issued
> because a
> change has occurred on the file server.  The problem that the cache
> managers
> have with the existing callback mechanism is that the cache manager has no
> idea what the trigger was.  From my perspective, the cache manager should
> simply be told the reason for the trigger.
>
> For example:
>
>     *     StoreData (newDV, offset, length)
>     *     StoreACL (newDV)
>     *     StoreStatus (newDV, status data)
>     *     CreateFile (newDV, filename, fid)
>     *     RemoveFile (newDV, filename, fid)
>     *     RenameFile (newDV, oldname, newname, fid)
>     *     Symlink (newDV, name, fid)
>     *     Link (newDV, name, fid)
>     *     MakeDir (newDV, name, fid)
>     *     RemoveDir (newDV, name, fid)
>     *     ReleaseLock (newDV, type, fid)
>     *     Cancelled
>
> By doing so the cache managers obtain the data they need without requiring
> any architectural changes to the file server.  These changes could be
> deployed
> today.

I'm inclined to agree, mostly.  I particularly like the idea of actually 
distributing directory changes to clients holding callbacks on a directory, 
as that could significantly improve performance in situations where there 
is heavy contention for a directory, by eliminating the need for clients to 
keep refetching that directory (if the client chooses to apply the update 
locally).

I agree with some of Matt's concerns about different triggers requiring 
different extended data, but I'd really like to see a solution that does 
not require a separate RPC for each trigger.



>> proc RangeInvalidateCallBack {
>> ~  IN  AFSCBFids *Fids_Array,
>> ~  AFSRangeCallbackSeq *CallBacks_Array
>> } multi = 65539;
>>
> Why is there a range of byte range changes?  A StoreData operation
> does not take a list of independent commits.  Each StoreData will
> result in a BreakCallBack(). > Proc AccessChangeCallBack

That's a sequence of byte ranges, to go with the sequence of FID's.  The 
idea is to let you send several updates at once, possibly on different 
FID's.  I suspect this is mostly useful on delayed callbacks.

> The Cache Manager does not track ACLs because it does not have
> enforcement responsibility and has no interaction with the Protection
> Service.  The purpose of the StoreACL BreakCallBack is to instruct
> the cache manager to flush the access rights history for the file.

Right; the CM doesn't need to know what the new ACL is; all it really needs 
to know is that the only change was to access rights.  Of course, currently 
it can't actually handle that any differently from any other status change, 
because it still needs to do a FetchStatus to obtain the new rights.

-- Jeff