[OpenAFS-devel] Breaking callbacks on unlink

[chas williams - CONTRACTOR]

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 <hozer@hozed.org> 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" <simonxwilkinson@gmail.com> 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
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>