Go for it. Having the two bricks knowing about each other must make
sense. It could also make reconstruction a lot quicker if the working
brick knew that the failed brick was working until time T then when the
failed brick comes up it's probably safe to say that files with an mtime
less than T-120
Same here, and the loadbalance sounds like a great addition.
Thanks,
Brent
On Tue, 1 May 2007, Majied Najjar wrote:
That makes all the sense in the world to me to have replication on the
server side. I especially like the idea about network failover and not
having to depend on client mounts
That makes all the sense in the world to me to have replication on the server
side. I especially like the idea about network failover and not having to
depend on client mounts to maintain consistency on the server side.
Majied
On Tue, 1 May 2007 09:05:28 -0700
Anand Avati <[EMAIL PROTECTED]>
here is a design proposal about some changes to afr and related.
currently AFR is totally handled on the client side, where the client
does the replication as well as failover. the AFR translator
essentially is doing _two_ features - 1. replication 2. failover.
In view of the recent race conditi
