--On Sunday, April 06, 2008 05:39:09 PM -0400 Jeffrey Altman
<[EMAIL PROTECTED]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
