Hi all, I personally believe that the replicated-distributed requirement to have at least 2 node during expansion, is not really practical.
It is not practical for low budget user, where might be only able to buy one machine at time, or add one hard disk at a time. It is also not practical for high budget user, even if they have budget to buy a 10K USD server with 12 disk, because of the requirement, they need to buy 2x10K USD server (overbudget) or 2x5K USD with 6 disk each (on budget but low disk size) If replicated-distributed can be implemented following Linux MD RAID 10, this will offer greater flexibility in term of starting up using gluster, because you can start using 1 node (no replication), then expand to 2 node (replication), then to 3 node (replication-distribution), then to 4 node and beyond Here is the layout of file when using Linux MD RAID 10 with 2, 3 and 4 disk: 2 drives 3 drives 4 drives -------- ---------- -------------- A1 A1 A1 A1 A2 A1 A1 A2 A2 A2 A2 A2 A3 A3 A3 A3 A4 A4 A3 A3 A4 A4 A5 A5 A5 A6 A6 A4 A4 A5 A6 A6 A7 A7 A8 A8 Moving from 2 node to 3 node should be resulted in this layout: 2 node: A1 A1 A2 A2 A3 A3 3 node: A1 A1 A4 A2 A2 A5 A3 A3 A6 A4 A5 A7 A6 A7 A8 A8 A9 A9 If an algorithm can be designed to favour the new empty node when writing a new file, and the file replicated on the older node, there is no need for rebalancing, as the new node is always preferred. As you can see, (with assumption that all file is same size) after 6 new file, the disk is automatically balanced. Comment? Thanks. -- Sharuzzaman Ahmat Raslan
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel