On Tue, 24 Jan 2012 14:28:18 -0800 Russ Allbery <[email protected]> wrote:
> 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. I disagree that OpenAFS has too many options; it has too many options that are useless (or poorly understood/documented). OpenAFS could use more options in various areas that are currently hard-coded, and could definitely use less in others. The number of times I have this conversation is depressing: User: Why does OpenAFS do X? Me: Because reason Y User: Reason Y doesn't affect us. Can we change it? Me: Not with the current code. Sorry. Most of the time it's where we drew a line in the ground for a speed/memory tradeoff, but sometimes it's for compatibility, like this. > 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. I think there are ways of solving this well, but I don't want to get into that here. > 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. They are certainly both non-POSIX, but one is at least... predictable. Consistent. Deterministic within the limited view of the processes interacting with the relevant file. It may not be what I expect from a POSIX-conforming system, but it's what I expect from "a" computer system. But I'm not trying to say that one is better than the other. Just that a reasonable person may want one over the other (and I'm pretty sure I know at least one that does). > 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. I can agree with this, but I do not see a reason to prohibit the administrator from making such decisions. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
