On Tuesday 26 April 2005 13:40, Steven Dake wrote:
> Hate to admit ignorance, but I'm not really sure what SCTP does.. I
> guess point to point communication like tcp but with some other kind of
> characteristics.. I wanted to have some idea of how locking messages
> are related to the current membership. I think I understand the system
> from your descriptions and reading the code. One scenario I could see
> happeing is that there are 2 processors A, B.
>
> B drops out of membership
> A sends lock to lock master B (but A doens't know B has dropped out of
> membership yet)
> B gets lock request, but has dropped out of membership or failed in some
> way
>
> In this case the order of lock messages with the membership changes is
> important. This is the essential race that describes almost every issue
> with distributed systems... virtual synchrony makes this scenario
> impossible by ensuring that messages are ordered in relationship to
> membership changes.
It sounds great, but didn't somebody benchmark your virtual synchrony code and
find that it only manages to deliver some tiny dribble of messages/second? I
could be entirely wrong about that, but I got the impression that your
algorithm as implemented is not in the right performance ballpark for
handling the cfs lock traffic itself.
If I'm right about the performance, there still might be a niche in the
membership algorithms, but even there I'd be worried about performance.
Obviously, what you need to make your case with is a demo. If anybody is
going to write that, it will almost certainly be you. You might consider
using my csnap code for your demo, because it has a pluggable infrastructure
interface which takes the form of a relatively simple C program
("csnap-agent") of which an example is provided that uses the cman interface.
You could simply replace the cman calls by virtual synchrony calls and show
us how amazing this algorithm really is.
http://sourceware.org/cluster/csnap/
All dependencies on cluster infrastructure - (g)dlm and cman - are
concentrated in that one "agent" file. Apart from that, the code depends
only on what you would expect to find in a standard 2.6 setup. You can even
run a non-clustered filesystem like ext3 on the csnap block device, so you
don't have to worry about setting up GFS either, for the time being. This
should be pretty much an ideal test platform for your ideas.
Regards,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
