> more feedback is always apprecitated, please shoot.
If I can jump in here on the "two mirrored bricks that don't need to
talk to each other" scenario.
Version 1.3 questions
* How do I cleanly shut down the bricks making sure that they remain
consistent?
* How do I add client hosts to the server.vol file? I've tried adding a
host and
killall -HUP glusterfsd
* 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"?
* 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?
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!
* 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.
* When rebuilding, will file-locking occur at a reasonable block size
rather than the whole file? Some of my astronomers have some big files!
Thanks for answering our questions so readily.
John
