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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel > -- Marcus Herou CTO and co-founder Tailsweep AB +46702561312 marcus.herou@xxxxxxxxxxxxx http://www.tailsweep.com/ http://blogg.tailsweep.com/
