On Thu, Jan 26, 2012 at 1:03 PM, Andrew Deason <[email protected]> wrote: > On Wed, 25 Jan 2012 23:04:57 -0500 > Derrick Brashear <[email protected]> wrote: > >> > With this particular issue, again, there are two irreconcilable desired >> > behaviors: >> > >> > - when accessing a legacy/misbehaving fileserver, yield an error after >> > N seconds of no progress >> > >> > - when accessing a legacy/misbehaving fileserver, hang forever in the >> > 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. -- Derrick _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
