[OpenAFS-devel] Re: Breaking callbacks on unlink

[Jeffrey Altman]

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

On 2/25/2012 5:42 PM, Troy Benjegerdes wrote:
> Let me propose the following:
>=20
> 1) on unlink, server broadcasts to all open callbacks something like=20
> the following: cache_unlink_or_forget_it(), which basically informs the=

> client that the file is being removed.

existing afs callbacks do not contain a reason.   they are sent over
an unauthenticated link and cannot be trusted.

what the client is told is by receipt of a callback is simply that the
file server is no longer going to notify the client of changes and that
something might have changed.  It is entirely up to the client to decide
whether or not it cares and when it does, it must issue a new
FetchStatus request to find out if something in fact did change.

> 2) If the client has both of the following:
> 	a) disconnected operation
> 	b) sufficient cache space for the whole file
>=20
> it can then pull the whole file into cache (or maybe must already have
> the whole file cached), and then the server can break the callback, and=

> get rid of the file, and the client now has deterministic unix remove-i=
t
> on-close semantics

by the time the client has received the callback it is already too late
to read any more data from the file server.  Attempts to read from the
FileID will fail with VNOVNODE.

> A possibly simpler approach is go ahead and break the callbacks on unli=
nk,
> and it's up to the client to make sure it's got enough cache space to k=
eep
> the whole file. Then it's the client's (and maybe sysadmin of the *clie=
nt*)
> to make sure there's enough space and something to ensure the files for=
=20
> which unix unlink semantics are important for will already be cached.

A saner behavior can be implemented if the file server knew the file was
still in use.  However, that is not possible with the IBM AFS RPC set.



--------------enig5315D201F38AAA0E4B4D46C8
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)

iQEcBAEBAgAGBQJPSW7uAAoJENxm1CNJffh4m9YH/0bYzif8MFWWO+2Cp2PHfWUj
Jzis4CiPvpqhGD/i5tiyJJ/5fioMeSgGo927Y01HvVpv7CKzfcVpUEz22adrtfNt
JRyO8UnrRgdutnfui8yjZeSLQx+ALnuZRt8nRLD72M7jUzkAAn0dxI2hdgHkOuA1
suFMUaNOPQlh4jcfRvN9XzKLHcMwHAAgaINhrLubIUaVGrC+XyhgNpzQb57VWtSh
/dic+k4q9gvrn7Od6b/aRK+WOMg5D94DEKe/1K/Wlnree8r0OPjF2reKXjKQ+Dbk
V7Nv+ZnFOW7OsuXKMp+i//nFYq+w+NMPM05Yrc9l9ORPBXuXMS4617cYFAt66lw=
=AsH4
-----END PGP SIGNATURE-----

--------------enig5315D201F38AAA0E4B4D46C8--