[OpenAFS-devel] Re: Breaking callbacks on unlink

[Russ Allbery]

Andrew Deason <adeason@sinenomine.net> writes:
> Russ Allbery <rra@stanford.edu> wrote:

>> Runtime configuration is usually the worst of all available options.

> "Usually" depends on how narrowly you're defining this situation. For
> scenarios where the current behavior is known to be faulty but must be
> retained for behavior with unknown extant legacy software, I often find
> runtime configuration to be the only avenue for improvement. The
> alternative is to forever restrict functionality to maintain
> compatibility with clients that a site may not care about. (er, or the
> other alternative is 'breaking' backwards compatibility, but I don't
> really consider that an option)

Runtime configuration is useful in this case for a migration plan, and
then should be removed in a later version in which the new behavior is the
only available option.  But it still sucks.

OpenAFS has way too many options.  OpenAFS should have fewer options that
actually work and are tested, instead of lots of options no one tests and
that therefore bitrot.

> This originated from someone else seeing this happen and inquiring about
> fixing it. It's not exactly critical, obviously, but I get the feeling
> it's one of those things leading to grumbling about afs having weird
> behavior for "no reason". It's not like the inconsistency actively broke
> an application, since it's hard for me to imagine that happening, but it
> sure makes any such situation very difficult to debug.

Breaking callbacks in this case would just give AFS a different type of
weird behavior for "no reason," though.

The POSIX behavior would be for the file server to retain the data of
files that are unlinked but have open file descriptors, but that would
require the file server to understand all sorts of concepts that would be
very difficult for the AFS protocol to express, like open file
descriptors.  Given that, I think we're chosing between several
non-POSIX-compliant options, none of which will work quite like what one
"expects" of a typical UNIX file system.

I don't know that I would pick the current behavior if we were making a
fresh decision today, but given how long-standing it seems to be, we
probably need a compelling reason to change it.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>