[OpenAFS-devel] Re: Breaking callbacks on unlink

[Matt W. Benjamin]

Hi,

I think you guys have established that it's mostly harmless for the file to continue to exist at the fileserver, but that seems to ignore the client semantics altogether.  Like, if a client is going to hoard the file in response to the callback, it must be able to do everything that the protocol specifies to enable that.  That seems to involve keeping its registration, or rather getting a new one.  So new clients can get a registration in the delete window?  Then when it's really gone, they'll get another break callback?  As Simon points out, without improving the callback interface to clarify the state of 'deleting' files, clients trying to actually to use the delete window regularly would degrade the fileserver.

Matt

----- "Andrew Deason" <adeason@sinenomine.net> wrote:

> On Mon, 27 Feb 2012 11:10:06 -0600
> "Matt W. Benjamin" <matt@linuxbox.com> wrote:
> 
> > But just to be clear, what exactly would be the proposed semantics
> at
> > the different clients?  Ie, using existing RPCs and callback
> > registration, or using new RPCs you would propose (to
> afs3-standards
> > ;)?
> 
> I can't speak for Troy, but at least what was in my head is that the
> wire is all the same; just that when the fileserver gets a RemoveFile
> RPC, if there are callback promises active on the file (or just
> 'always'), the vnode doesn't actually go away until X minutes after
> the
> last callback goes away.
> 
> I suppose there's also potential issues of that there's no way for a
> client to really verify something is gone (for either space purposes,
> or
> confidentiality or something). I'm not really trying to propose
> actually
> doing this or anything, though; it just seems like from talking with
> chas that it's the best that can be done without altering wire
> protocol.
> Whether or not that's acceptable I'm not really dealing with; just
> sharing some ideas :)
> 
> -- 
> Andrew Deason
> adeason@sinenomine.net
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

-- 
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