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" <[email protected]> wrote: > On Mon, 27 Feb 2012 11:10:06 -0600 > "Matt W. Benjamin" <[email protected]> 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 > [email protected] > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
