[OpenAFS-devel] Re: Breaking callbacks on unlink

[Andrew Deason]

On Mon, 27 Feb 2012 12:25:28 -0500 (EST)
"Matt W. Benjamin" <matt@linuxbox.com> wrote:

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

When it's really gone, nobody gets anything. The file only goes away
when there are no active callback promises for X minutes, so the
fileserver hasn't promised to anyone that it will notify them of
anything. That part of it doesn't change anything wrt fs<->client
semantics.

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

Yes, of course. If someone holds open a file on some system and you try
to delete it, the file will stay around forever as long as that
reference is kept on that client; that's the idea :)

If you just mean there's no way for a client to say "really delete this
file, I don't care if someone else is using it", then yeah, there's no
way to do that without updating the protocol. That's what I was trying
to say with the concerns about space usage and confidentiality or
whatever. I don't know how critical it is for various people, but it is a
problem, sure; as far as I'm aware, it is the only problem with such an
approach.

That issue can seem a bit... less important for the general case to me,
since I don't even know what the userspace application-level interface
looks like to "really delete" a file beyond an afs-specific pioctl. You
don't have this ability even for local filesystems, if you're an
unprivileged user trying to delete a file held open by root. Anything
concerned with the file being recovered I thought would usually try to
"shred" the file by overwriting it with stuff anyway, which still works
here. And anything concerned with getting the space back... other
filesystems have the same "problem" with no workaround.

I'm not objecting that such functionality be added to the protocol; I'm
just saying, even in the meantime with the current wire protocol this
seems solvable, practically speaking. I'm not going to work on it, but
if someone really cares... it seems to me like the described strategy
would work.

-- 
Andrew Deason
adeason@sinenomine.net