On Tue, 24 Jan 2012 15:10:55 -0800 Russ Allbery <[email protected]> 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 [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
