[OpenAFS-devel] Re: Breaking callbacks on unlink

[Jeffrey Altman]

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

On 1/26/2012 10:09 AM, chas williams - CONTRACTOR wrote:

> the "breaking callbacks on unlink" is yet another drop in this bucket
> of non-deterministic behavior.  as andrew said, a user asked him why it=

> sometimes worked one way and sometimes another.  while not as serious a=
s
> the idledead problem, it still leads to questions in people's minds.
>=20
> if i give you a calculator and it works fine except that square root
> sometimes gives the wrong answer, would you use it?  did i forget to
> tell you that the square root might be wrong?  how do you know when the=

> square root will give the right answer?  wouldn't you prefer to know
> that square root will always be wrong instead of possibly right.
>=20
> the argument with regard to breaking the callbacks is getting the same
> behavior every time regardless of whether or not you like the result. i=

> would argue this should be the default and if there is any flag, it
> should be "enable legacy unlink behavior that hinges upon what
> you might have to done to precondition your local cache".


There are two completely different issues here:

1. What is the semantic behavior of the existing RPC?

   It is that the callback break is not issued when the link count
   hits 0.  This is the behavior of the RXAFS_Removefile RPC and
   it cannot change.

2. What are the semantics that would be desired by the community?

   Here there are a couple of possibilities:

   a. Consistent behavior such that when the link count hits 0
      file descriptors on UNIX can safely continue to use it.

   b. Consistent behavior such that when the link count hits 0
      the callback is broken and cache managers are required to
      invalidate any open file descriptors or handles.

   c. Client requested behavior when a client issued an extended
      FetchStatus request.

   Any of these can be adopted.  The way they get implemented is
   by supporting new RPCs.

OpenAFS cannot stop a site from applying a local patch to do whatever
they want.  However, OpenAFS will not accept patches that intentionally
modify existing semantics UNLESS the existing semantics pose a security
issue.  Examples where we have done this in the past include access
control enforcement and setuid functionality.

Jeffrey Altman


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

iQEcBAEBAgAGBQJPIY7aAAoJENxm1CNJffh4qqEIAOPsgu+7RYjWcF2o/kzttqcJ
xGTQf9ljwgchRiLj9TLomCUxAL1o8W7RvplGXIUkDy5KjJK68kPmadqhRMOdW0uZ
ZgfK3sa4GiWFMaGq6RMPQ0GFFTMnfDetfAiODihTsAWsQ8bH/ERoO14Q1F80n4ix
sensGB8kyJSOZyEd7FEda+YaS9UY1Rc1JIxiZoos6G304zTTLcDs1cLALYgeyjc9
hv2sHOOgUsluxyiohjqqCVCRtCgDsHbQNoCLqDC9IdMCTItEs9ZhwO867pUR6CWs
LES81WizVpdzR/9MvLFxYlFBxc8pp4JMDHmbRyRtyY65F2FGOqZfIlHOeVe4wxw=
=cAf8
-----END PGP SIGNATURE-----

--------------enigB04876FB765672D5B570DDA7--