vrs-development
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Vrs-development] IBM Token Ring Thingy...


From: Eric Altendorf
Subject: Re: [Vrs-development] IBM Token Ring Thingy...
Date: Fri, 3 May 2002 16:56:17 -0700

On Friday 03 May 2002 16:04, Bill Lance wrote:
> I agree that transactions are the way to go.  However,
> a two phase commit is a problem, if you mean the
> second phase as a verification step.  There is no
> process that we can afford to hold pending
> verification.  We might run a background monitor
> tracing all transaction results, but if we design this
> right, that shouldn't be necessary.  And it would
> certainly incresase the overhead significantly.

You can't have distributed transactions without a two phase commit... and you 
can't have consistency without transactions.

For a definition of 2PC, see:
http://www.vermicelli.pasta.cs.uit.no/ipv6/students/andrer/doc/html/node18.html

This is the point I've been trying to make about the distributed filesystem.  
For example, there is no way to guarantee that nodes don't store conflicting 
versions of files without forcing the coordinator to, upon every write 
request, contact every LDS node which stores the block in question, ask it to 
postpone reads of that block, ask it to write the new data, and then either: 
(1) wait to receive a success message from every node, then send out a second 
message saying the write is complete, and the system can continue, or (2) 
timing out or getting a failure reply from an LDS node, in which case the 
coordinator must send out an abort message and every LDS node must undo the 
write.

This is why these sorts of systems are so complex and hard to write.  This is 
what keeps Oracle in business. :-)

> We are trying to maintain an organic looseness between
> the LDS elements.

I understand the drive to do this, but to acheive full "looseness" you'll 
have to accept the possibility of inconsistent data in whatever you're 
talking about (e.g., the cluster image, or the data on the distributed 
filesystem).

The question is whether we need to guarantee consistency or not.  It sounds 
like for the cluster image, we may not need to guarantee consistency.  For 
the filesystem, I think we probably do.

Eric

-- 
"First they ignore you.  Then they laugh at you.
 Then they fight you.  And then you win."             -Gandhi



reply via email to

[Prev in Thread] Current Thread [Next in Thread]