[OpenAFS-devel] Re: Breaking callbacks on unlink

[chas williams - CONTRACTOR]

On Wed, 25 Jan 2012 17:40:36 -0800
Russ Allbery <rra@stanford.edu> wrote:

> The software needs to work first.  If it's working, I have a pretty high
> tolerance for options and configurable behavior (hell, look at pam-krb5).
> When it doesn't work, that tolerance drops considerably, particularly when
> attempting to diagnose why it doesn't work involves multiple iterations
> through various options that are annoyingly unrelated to the problem of
> the file system not working.  And, to take that a step further, I'm
> getting pretty sick and tired of having to assemble a fragile and
> ever-changing set of random flags, options, and tuning parameters to
> achieve the basic goal of having working software.

unfortunately afs meets your first requirement -- afs works -- most of
the time.

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 as
the idledead problem, it still leads to questions in people's minds.

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.

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".