[EMAIL PROTECTED] writes:
> Oh yeah? Find me another system where you can crash even more than one
> server and still keep the system functioning decently... ;-)
I'm afraid you will not find much of a sense of humor among many
Transarc customers regarding this issue. The effect of the current
situation is to occasionally make us look like fools to our users for
having chosen AFS technology. We like to think that choosing AFS
was a good decision.
> | I hope that the pts changes will make it do what I need it to; We've
> | been waiting for R/O access out of quorum since 1993. Without R/O
> | access out of quorum, AFS is really unsuitable for widely distributed
> | production environments.
>
> I dont think that quorum is the main issue about wide-area access, but
> that is neither here nor there.
Unfortunately, a significant number of your customers do. Since you
participated in a lengthy discussion of this issue about a year ago,
I'm surprised and alarmed that you don't seem to be aware of this.
> The point is anything weaker than
> transactional semantics when using replication for such metadata is
> known to be a root cause of `bad' behaviour in almost all distributed
> systems. If you weaken it (for example, by giving out info outside of
> quorum), you will have much more hairy problems that just WAN access.
This is all very interesting, but the question is whether it Transarc
has addressed the problem its customers wanted it to address. I would
simply like to know one way or the other. Please provide us with a
user-view description of the functionality changes in 3.4.
For reference, here is a description of the problem as I see it:
At AFS 3.3, when an AFS server (assume it covers all services) gets
cut off from the rest of the AFS servers in its cell, users at
workstations which have access to this cut-off server may be unable
to access files in volumes which exist on it.
The details of what type of access is lost under what circumstances is
interesting, but of questionable relevance. The question is whether
there is any good reason why these users should not have normal access
to their files. Since it seems likely that the answer to this
question will depend on the environment, it may be best to make any
solutions optional.
I hope I haven't come on too strong here, but you have definitely
got me worried.
-Rick
--
|Rick Cochran 607-255-7223|
|Cornell Materials Science Center [EMAIL PROTECTED]|
|E20 Clark Hall, Ithaca, N.Y. 14853 cornell!msc.cornell.edu!rick|
| "Workstations - I bet you can't eat just one!" |
