> And you always got the option to reduce the quorum statically to "1" This is a very interesting tidbit of information. I was wondering if there was some way to preload data on a brick, and I think you might have just given me one. I have a volume of three peers, one brick each. Two peers have a fast connection, the third one has a very slow connection. In normal operation this doesn't matter, because there will only be fairly small changes to the filesystem over time. However, when loading the initial data on the volume before it becomes operative, the one slow connection becomes a bottleneck for two fast ones. So I'm thinking now whether I could 1. join the three peers and build the empty volume, 2. take the slow peer off-line, 3. load the data on the crippled volume, so that it is written to the two fast peers that are still online, 4. take the two fast peers offline and put the slow peer online, 5. reduce quorum to 1, 6. load the exact same data locally to the slow peer, and 7. put the two fast peers back online and increase quorum to 2. This would lead to all three bricks having the exact same data without the delay of the slow transfer, but it will only work if the exact same metadata are created for the same files during the two separate loads. That is, if a given file foo always produces the exact same metadata, after loading foo to different bricks on different occasions, the metadata of all bricks will be identical and no healing would be needed. Is that so, or am imagining impossible acrobatics? Z ________ Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://meet.google.com/cpu-eiue-hvk Gluster-users mailing list Gluster-users@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-users
