[OpenAFS-devel] Re: Breaking callbacks on unlink

[Andrew Deason]

On Tue, 24 Jan 2012 14:28:18 -0800
Russ Allbery <rra@stanford.edu> 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
adeason@sinenomine.net