[OpenAFS-devel] Breaking callbacks on unlink

[Andrew Deason]

Someone asked me about this recently, and I don't have a good
explanation of why this is the current behavior.

Currently, a fileserver will NOT break callbacks for a file that is
being removed. If it gets unlinked and the link count remains above 0,
we of course do break callbacks since that's just a number changing in
the metadata, but we don't when the file actually goes away. This is
this section in the fileserver, in afsfileprocs.c in SAFSS_RemoveFile:

    /* Handle internal callback state for the parent and the deleted file */
    if (targetptr->disk.linkCount == 0) {
        /* no references left, discard entry */
        DeleteFileCallBacks(&fileFid);
[...]
    } else {
[...]
        /* tell all the file has changed */
        BreakCallBack(client->host, &fileFid, 1);
    }

This can cause rather confusing behavior when a file gets deleted out
from under a client. If you have a file open that another remote client
deletes, whether or not you can still read data from that file is
dictated solely by whether or not you have the relevant data cached
(and have a valid callback, etc). And that is not controllable by the
application or even administrator, since stuff may get kicked out of the
cache at any time, etc etc.

Of course, ideally we don't have files deleted out from under clients.
With some design work I assume it's possible to have clients somehow
signify they want a sillyrename instead, but I'm not talking about that.
What I'm wondering is: why don't we just always break callbacks? If we
did that, a client would always get read() errors when a file was
deleted out from under it. Right now it just happens "sometimes", which
can make it hard to figure out what is going on.

This is one of those things where I'd consider the behavior to just be a
mistake, except the fileserver very deliberately does this. So... does
anybody know why?

-- 
Andrew Deason
adeason@sinenomine.net