i would do it slightly differently. on the first unlink the file would be silly renamed by the fileserver (and break callbacks on the parent directory so clients can't easily get a new reference). put the file in the unlink queue. if a callback comes in for the file, reset the unlink timer for this file each time.
this should get posix-like behavior without too much extra effort. yes, the posix behavior does have the potential of using space without being easily noticed. it is a trade off. On Sun, 26 Feb 2012 18:59:54 -0600 Troy Benjegerdes <[email protected]> wrote: > 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 > _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
