On Wed, 25 Jan 2012 17:40:36 -0800 Russ Allbery <[email protected]> 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". _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
