-----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----- _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
