I have in mind now a modification to the fileserver to add an 'unlink queue' that has some sort of sane default limits on number of entries and time in the queue that would give a 15 minute to 1 hour residence time on an average fileserver.
This gives the following benefits: 1) performance improvements by defering unlink vicep updates, and allow many updates to be batched at once 2) an 'omg I deleted all my files by accident' recovery mechanism for users (I suppose this could be implemented by allowing the user to request that all files still in the unlink queue be moved into the .backup volume) 3) predictable behavior for clients, which could choose to cache the entire file once they notice an unlink. Does this require any new RPCs for functional correctness? (I can see the potential for at least 1 new one for performance) On Sat, Feb 25, 2012 at 08:36:53PM -0500, Matt W. Benjamin wrote: > Hi, > > I missed this on first reading. Obviously, the semantics of a promise to > callback cannot be interpreted as a license to poll. I did not imply it. > > Regards, > > Matt > > ----- "Simon Wilkinson" <[email protected]> wrote: > > You'd also require that a client > > constantly refresh callbacks for any files which it has open, which > > has potential fileserver performance implications. > > > _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
