[Top][All Lists]

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

Re: [Gluster-devel] AFR filesystem inconsistency?

From: Martin Fick
Subject: Re: [Gluster-devel] AFR filesystem inconsistency?
Date: Sun, 17 Feb 2008 20:23:53 -0800 (PST)

--- Anand Avati <address@hidden> wrote:
> In the current design, whenever one or more server
> goes down, or comes up, there must be atleast one
> common server between the previous subset and the
> new subset of servers, who can carry on the
> self-heal knowledge to the newly
> added servers.

Sure, that makes sense.  Seems like an OK limit to
live with, the only issue is ensuring that!  Currently
there does not seem to be anyway to ensure that this
requirement is met.  It seems like this is a more
important (or perhaps tangential) idea to proactive
self healing which you imply you have plans for.  

Are there any plans to make a simple algorithm that
just keeps track of which servers have gone down
(before keeping track of the deltas)? This would allow
each server to calculate whether there is at least one
remaining consistent server.  If there is, then a
server that comes up can know whether it is joining a
consistent cluster (or it was itself the last know
consistent node), or simply refuse to start serving
since if the live nodes are not sufficient to make the
cluster consistent.  That is why I was asking for a
hook to know when data cannot be written to a node. 
With a hook like this, even a shell script could
probably keep state of the cluster and ensure

I ask specifically about the plans not because I am
trying to speed up development (I can wait, I use drbd
currently), but rather just to try and understand
where you're headed and to see if perhaps there isn't
a very simple solution that is being overlooked which
could be implemented before smart delta tracking.

> The future versions we plan to implement proactive
> selfheal where we record deltas of changes, and
> this need should go.

That would be cool (kinda like drbd), but to me that
is merely an optimization and secondary to simply
insuring that the cluster is consistent when serving



Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

reply via email to

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