On Fri, 24 Jan 2014 11:41:35 -0500 Jeffrey Hutzelman <jh...@cmu.edu> wrote:
> The problem is the one-off clients that make _one RPC_ and then exit. > They have no opportunity to remember what didn't work last time. It > might help some for these sorts of clients to use multi, if they're > doing read-only requests, and probably wouldn't create much load. > However, for a call that results in a ubik write transaction, I'm not > entirely sure it's desirable to do a multi call. That will require some > additional thought. At least we could multi call the VOTE_GetSyncSite call, perhaps, in situations where we actually use GetSyncSite. > In the meantime, another thing that might be helpful is for clients > about to make such an RPC to query the CM's record of which servers > are up, and use that to decide which server to contact. A quick > VIOCCKSERV with the fast flag set could make a big difference. We have some code to implement this and honoring the client server preferences; finishing it I think just got buried behind higher priorities. -- Andrew Deason adea...@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info