[OpenAFS-devel] Re: Breaking callbacks on unlink

[Andrew Deason]

On Tue, 24 Jan 2012 15:10:55 -0800
Russ Allbery <rra@stanford.edu> wrote:

> Then we should pick better tradeoffs or dynamically tune.  Not add
> more options.  Look at the mess with cache tuning, and the mess with
> file server tuning.  The existence of the options rarely helped
> anyone; what really helped people was to change the code to
> dynamically tune.

To say that the 'mess' with these is solely because of the number of
options is, to be perfectly honest, ridiculous. There are countless
other software projects that have many runtime options to affect tuning,
and they are not nearly as... inscrutable to tune as we are.

And picking a tradeoff that works for everyone is _impossible_. For many
things, dynamically tuning options with the current architecture is slow
or _impossible_ (do you want to allocate fileserver callbacks
dynamically forever, until the OOM killer kicks in?). A lot of this can
be solved by rewriting large parts of code and rearchitecting, that's
true. But when is that going to happen? The fact that nobody has the
time or wherewithal to even try to make them constant-yet-configurable
does not make me confident that they will be fixed to the point of not
benefiting from configuration any time in the near future. And
meanwhile, the user is stuck with a constant.

If you want the _end goal_ to be getting rid of them, sure. I can
certainly agree with your earlier comment that they should be considered
as part of a transition or migration plan. The notion of seeing the
options as reflecting deficiencies in the code (and therefore something
to be removed) I agree with. But right now we have those deficiencies,
and they are not reflected as runtime options, which has bad results
when we are unable to predict the future.

> OpenAFS is open source.  The administrator can always make the
> decision.  Adding an option means that we, as a project, are
> supporting the option.  Every setting of the option.

The administrator does not always have the ability to make such a
choice, because they are not always able or willing to change the code.
You don't have to be a C programmer to know that you want the fileserver
to do X.

I do not agree that adding an option inherently implies that the project
supports the use of it: "the use of this option is for experimentation
and is strictly unsupported". Other projects do this; I thought Linux
kernel devs often refused to look at any 'tainted' panic reports. (We
already sort-of do this; some options are effectively documented as
"don't change me".) I know that when you do something like that, people
won't listen to it and will expect it to be supported anyway, but that
doesn't change the fact that it's not.

I understand the desire to not include those options, because it means
you have to throw away bug reports, or accept them and effectively try
to support them anyway, neither of which is good. But I mean, come on,
for e.g. a hashtable size? 

> We don't have enough manpower to support the behavior we already have.

We don't have enough manpower to make everything dynamic and
automagically tuned to fit everyone's needs. (At least, without funding.
These statements are my own opinion and not that of my employer, &c &c)


I think some people underestimate the wide variety of sites'
expectations of OpenAFS behavior (or just "software in general"). At
this point I am very used to seeing wildly different and conflicting
requirements that people just "expect", so I am always very unconvinced
that any single option can be suitable for everyone.

-- 
Andrew Deason
adeason@sinenomine.net