Hi, Krishna Srinivas wrote: >> Interesting, so any existing data on the disks will not be affected? How >> does that work? Does this mean I can fill the disks a-priori before >> unifying them? > > Unify checks with all the subvols on where it is before opening. > Yes you can have pre-filled data before unifying them. OK, thanks for the clarification. >>>> - What would happen if I added another brick, say another disk to the >>>> existing set on one of the machines? Would it break the round-robin >>>> scheduler that I am using? I see from the FAQ that this should work with >>>> the alu but will it work with rr? >>> ALU will be useful when you add servers later. i.e it will see free >>> diskspace and schedule creation of new files there. RR will just >>> round-robin. >>> >>> You can experiement with the new "DHT" translator in place of unify. >> OK, I can do that, I see dht does not need the extra namespace disk, so I >> guess I can clear out that directory. > > Note that DHT is a separate cluster xlator and not scheduler. Sorry, I understand and messed up the terminology. > You are using AFR over unify, The problem is when one of the servers > on unify goes down AFR will see missing files and recreate them, so > when the downed server comes back up unify will see those files on two > subvols. OK. So this will persist whether I use dht or unify, right? So what is the way out of this problem. >>> When you have afr over unify and one of unify subvol goes down, afr's >>> selfheal will create missing files which you don't want to happen. >> OK, so you are saying I need to simply switch to using dht, remove the >> namespace directory and continue with the setup and this problem will not >> occur? > > No, DHT is not related to this. OK, sorry to be slow but now I am confused. What should I do to my setup to not face these problems? Thanks. cheers, prabhu
