[OpenAFS-devel] Breaking callbacks on unlink

[Derrick Brashear]

On Tue, Jan 24, 2012 at 2:52 PM, Andrew Deason <adeason@sinenomine.net> wro=
te:
> 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:
>
> =A0 =A0/* Handle internal callback state for the parent and the deleted f=
ile */
> =A0 =A0if (targetptr->disk.linkCount =3D=3D 0) {
> =A0 =A0 =A0 =A0/* no references left, discard entry */
> =A0 =A0 =A0 =A0DeleteFileCallBacks(&fileFid);
> [...]
> =A0 =A0} else {
> [...]
> =A0 =A0 =A0 =A0/* tell all the file has changed */
> =A0 =A0 =A0 =A0BreakCallBack(client->host, &fileFid, 1);
> =A0 =A0}
>
> 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
>
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel



--=20
Derrick