[OpenAFS-devel] Re: Breaking callbacks on unlink

[Derrick Brashear]

On Thu, Jan 26, 2012 at 1:03 PM, Andrew Deason <adeason@sinenomine.net> wro=
te:
> On Wed, 25 Jan 2012 23:04:57 -0500
> Derrick Brashear <shadow@gmail.com> wrote:
>
>> > With this particular issue, again, there are two irreconcilable desire=
d
>> > behaviors:
>> >
>> > =A0- when accessing a legacy/misbehaving fileserver, yield an error af=
ter
>> > =A0 N seconds of no progress
>> >
>> > =A0- when accessing a legacy/misbehaving fileserver, hang forever in t=
he
>> > =A0 face of no progress
>>
>> I don't think anyone wants this.
>
> I saw some emails to you today that sounded like someone wanted it :)
>
> But sure, some people may want something like that. Some people want
> hardmount. (Not saying we need an option for that at this time or
> anything, though.)

well, we have an option for hardmount, and have since ibm afs. (and
possibly that option should include no idle dead time,
because you signed up to retry forever)

>> > I believe/assume what is being considered "right" is the latter
>> > option.
>>
>> ?
>
> I definitely heard some advocacy for this the last time we were arguing
> about this (how the fileserver-side should make this determination,
> which is true, but...). But yeah, this isn't what went in.
>
>> > And, although sometimes it seems like this idea is
>> > unfathomable to some people in the community, some people _do_ exist
>> > that do not place cache consistency at their highest priority.
>>
>> The problem there, to me, is only when those people wish to
>> participate in the global AFS namespace, which is a second issue here,
>> the "play nice or go home" issue.
>
> Well, I was talking about idledead stuff here, specifically client
> behavior, which isn't going to screw up another client.

disagree. not *directly*. but it's a problem, an errant client can,
when talking to an older server,
deny service to other clients. that's "screw up" in my book.

> I think that
> matters much more when you're talking about server behavior, in which
> case, yes, certainly.




--=20
Derrick