Name-space volume is only a cache. If lost, it will automatically rebuild. How ever without AFR, NS-cache volume becomes a single point of failure. My recommendation is to not put ns-cache on AFR for now. 2.0 releases addresses this issue using "distribute". If you starting fresh, I recommend "distribute" (in 2.0) over "Unify". Distribute is faster than Unify and has no centralized name space cache requirement. 2.0.0rc2 is coming next week. It is relatively more stable than 1.3.x. "AFR" has been renamed to "replicate" in 2.0. It has atomic write support by default, which takes some performance hit. There are some config options to disable atomic write support and make it work like 1.3's AFR. We have addressed the atomic write performance issue in rc2 release to an extent. We will continue to put a lot of priority behind replication feature moving forward. -- Anand Babu Periasamy GPG Key ID: 0x62E15A31 Blog [http://ab.multics.org] GlusterFS [http://www.gluster.org] The GNU Operating System [http://www.gnu.org] Lior Goikhburg wrote: > Hello > > Got a production environment with 4 servers: 2 pairs of AFR'ed servers > and Unify between the pairs (raid 1+0 functionality). > Does it make sense to put the Unify's NS volume on an AFR cluster, or > there is no need for any redundancy for NS ? > > Thanks a lot in advance, for taking time to answer. > Lior.
