On Tue, Jan 24, 2012 at 2:52 PM, Andrew Deason <[email protected]> wrote:
> 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.
Breaking callbacks on the parent implicitly tells you the file is
gone: it's not in the directory listing anymore.
Now, what the rationale is beyond that, I couldn't tell you, but I
would speculate that it was used as some form
of IPC mechanism at some point.
> 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
> [email protected]
>
> _______________________________________________
> OpenAFS-devel mailing list
> [email protected]
> https://lists.openafs.org/mailman/listinfo/openafs-devel
--
Derrick
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
