[OpenAFS-devel] Breaking callbacks on unlink

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig11186E1B310DD55677966662
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 1/24/2012 2:52 PM, Andrew Deason wrote:
> Someone asked me about this recently, and I don't have a good
> explanation of why this is the current behavior.
>=20
> 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:
>
> [...]
>=20
> 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?

I doubt anyone on this list was present when this code was implemented.
My guess is that the purpose behind it is to ensure that open file
descriptors on a client are not invalidated behind the back of the
process that holds them.  On UNIX, a file whose link count goes to 0 is
still accessible to processes that have them open.  The current approach
does permit that for a short window of time provided that all of the
required data for the file is cached.  There are plenty of scenarios
where it won't work:

 * callback expired long ago but file descriptor still open

 * not all required data cached either due to sparse reads or file
   larger than cache size

 * cached data flushed to make room for other things

The file server could be smarter about things and avoid an immediate
file deletion when the link count hits 0 if there are callback
registrations or a non-zero lock count.

The cache manager can also be smarter and attempt to avoid discarding
cached data for files with open file descriptors unless there is no
other option.

If/when the proposed advisory RXAFS_Open RPC is implemented the open
reference could also be used as an indication that the file data should
not be immediately discarded.

You are correct that breaking the callback immediately would provide a
more uniform behavior but it would also break some existing use cases
that work today.

Jeffrey Altman




--------------enig11186E1B310DD55677966662
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJPHx24AAoJENxm1CNJffh4NncH/2UyCaGkKaFIXZVYI+goEmS+
DAda93UJP3G/8h2ZGWLH2ElERdv3PezwyESRc8EewlQhai3tQWWT5II3uFwZk88N
D/C7CxSpXpPI6JEWWZqBwlvQVlCxm/5mIMNAbAuMKxyDDLiRHmQVtlXFo//jpmcg
hoCV7IWAf+eTarHRHdmhb3LPcmzfMTLtTywtqVOwaqfRtjyVlWVWsfgaKF0PXmju
wmydyQuDn5c7dX2DTYpQ1WTv6lGYrpZmazwahKvTpPsPP+d8+cU28pjsZ6YuIvv3
zWGo5Ae/iuotsj3bC0SvoihH4N//na7FYgJTLFEluR2cyay3iJAvHG/DZSvtY3o=
=GdbH
-----END PGP SIGNATURE-----

--------------enig11186E1B310DD55677966662--