[Gluster-devel] Crawling and indexing hardware

[Marcus Herou]

Hi

I don't know if you guys are familiar with JGroups but if something like
that exists for c/c++ I think it could be something worth looking at.

Quick about the part I like with JGroups and often use when I'm building
clustered stuff without the master/slave[s] model. Whenever a new member
joins a voting process starts to identify all members and to see if the new
member should deem itself as coordinator, in fact the first to join becomes
coordinator. If a coordinator leaves then the second to join becomes coord.
This project is very stable and have helped me out building clustered caches
with distributed locks, striped [and or] raided data across servers etc.

Yet another nice thing is that the config part becomes minimal since the
servers do not need to know about each other in advance. So you can
basically just add another server and tell it to join "clusterX" and then
you can write code which do smart stuff on the "join" / "leave" events.

I guess Heartbeat is such a project if I'm not totally mistaken, at least
parts of it work like this right ?

But introducing a component like this elevates complexity of course and can
make the rest a little unstable. Come to think about it... Is 1.4 something
like this perhaps ?

Kindly

//Marcus



On Fri, May 9, 2008 at 7:02 PM, Kevan Benson <kbenson at a-1networks.com>
wrote:

> Anand Avati wrote:
>
> > When the server that dropped out reconnects, it's version will be higher
> > > than the new (reset) version, and it's old file will clobber the new
> > > file.
> > >
> > >
> > This is not entirely correct. This can *potentially* happen if the two
> > clients (the client who created the first file and the client which
> > re-created the file) are out of sync in time. AFR keeps the client
> > system
> > create time in the xattr and uses that as a major version number (the
> > other
> > thread discusses changing this major number to be equal to the parent
> > dir
> > minor number).
> >
> > If time(system1) - time(system2) < wall_time(file1) - wall_time(file2)
> > then
> > there is no data corruption.
> >
>
> Again we come back to the issue of the servers needing their time synced.
>  I keep thinking that some way to provide a stabilized agreed upon time for
> all cluster members would do away with this problem.  NTP might just not be
> as good a solution as something provided in cluster, because then AFR
> members could decide to not participate if they couldn't agree and sync to
> the cluster time.
>
> Also, to what precision is the time saved?  I can imagine modify, move and
> create operations happening in quite a short time period.  Short enough to
> be sub second if that's the only precision being kept, or possibly within
> the drift of ntp synced systems for sub second precision.
>
>
> --
>
> -Kevan Benson
> -A-1 Networks
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>



-- 
Marcus Herou CTO and co-founder Tailsweep AB
+46702561312
marcus.herou at tailsweep.com
http://www.tailsweep.com/
http://blogg.tailsweep.com/