[Gluster-devel] Gluster Recovery

[Anand Avati]

> 
> Version 1.3 questions
> 
> * How do I cleanly shut down the bricks making sure that they remain
> consistent?

For 1.3 you have to kill the glusterfsd manually. You can get the pid
from the pidfile (${datadir}/run/glusterfsd.pid)


> * How do I add client hosts to the server.vol file? I've tried adding a
> host and
>     killall -HUP glusterfsd

you mean 'option auth.ip.allow' lines? glusterfsd does not support
-HUP (yet). you have to kill and start freshly for now.

> * Do the bricks know about each other and their clients' replication at
> all? What if one client has "replicate *:2" and the other "replicate
> *:1"?

no, bricks dont know about each other. they not only dont know their
client's replication, but they dont even know whether they are being
used in a unify/afr/stripe too. all clients are expected to use the
same config file, hence the option is provided to 'fetch' the spec
file from one of the servers during mount (glusterfs -s SERVER) so
that it is convinient to maintain a centralized spec file which all
clients use.

> * Could race conditions ever lead to the different bricks having
> different data if two clients tried to write to the same mirrored file?
> Is this the reason for using the posix-locks translator over and above
> the posix locks on the underlying bricks? 

you are right, two clients writing to the same region of a file are
expected to use posix locks to lockout their region before editing in
an AFR scenario.

> Version 1.4 requests
> 
> * A mirror-consistency check command. Presumably this would be a fairly-
> small addition to the rebuild code. A danger of all mirroring schemes is
> that they can hide underlying problems until it's too late!

the 'self-heal' feature is aimed to be this, which, in runtime keeps
checking for inconsitoncies and fixes them 'on-the-fly' in a proactive
fashion.

> * A quorum that would require two out of three three mirrors (or N out
> of 2*N-1) to be able to talk to each other or for two mirrors to be able
> to talk either to each other or a quorum-server. This is to avoid data
> inconsistencies after a temporary disconnection. Perhaps an isolated
> mirror could be read-only.

i'm thinking about this. will get back to you later about it.


> * When rebuilding, will file-locking occur at a reasonable block size
> rather than the whole file? Some of my astronomers have some big files!

these level of details are not yet frozen. your suggestions will
surely be considered.

thanks!

avati

-- 
ultimate_answer_t
deep_thought (void)
{ 
  sleep (years2secs (7500000)); 
  return 42;
}