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

[Matt Benjamin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jeffrey Altman wrote:
| Matt Benjamin wrote:
|> Changes to file access permissions are added, because they were
|> enumerated by Jeff Altman as of interest.  Some details in this area are
|> not finalized, and feedback/discussion is requested.  Locking specific
|> change notifications are omitted (just the NotificationType flag is
|> included) to simplify discussion.  We expect to send a separate proposal
|> on locking interfaces.
| You misunderstood our discussion.

Our discussion was terminated by you you, before I could get any
clarification on your ideas.

ACL changes are not an area of interest.
| They are one of the reasons that BreakCallback() is executed in the file
| server.
|
| The full list includes:
|
|    * StoreACL
|    * StoreData
|    * StoreStatus
|    * RemoveFile
|    * CreateFile
|    * RenameFile
|    * Symlink
|    * Link
|    * MakeDir
|    * RemoveDir
|    * ReleaseLock
|    * when the callback is dropped by the file server due to lack of space

Ok.  Using the pseudo-prototypes below, there are a variety of disjoint
messages, tagged by a type.  Do you object to the idea of distinct
CallBack RPCs to pass these data?  I would prefer not to define a giant
structure, and although rx seems to support a "union" type, I don't see
anyone using it in published RPCs.  That preference was implicit in the
document I sent.

|> typedef    AFSRangeInvalidateCallBack AFSRangeCallBackSeq<AFSCBMAX>;
|>
|> ***
| 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.

We don't seem to be disagreeing on the merits.

However.  I suggested the "bulk" mechanism as an optimization which
could be performed at the file server, to reduce storms of call backs on
busy files.  Bulk operations are already a feature of the AFS protocol.
~ Is that really not relevant to the discussion?

I would not like to author a potentially expensive feature without due
consideration for efficiency.  In fact, as would envision implementing
this feature, there would be a queue of calls in any case.

Thanks,

Matt


- --

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH+UkrJiSUUSaRdSURCNsbAJ90tmRkIjXFnQkiIjHvRyI9c3rq2QCfVAfL
KmPYQI6L7OY/XMrgjkC77Ko=
=jMhr
-----END PGP SIGNATURE-----