Red Hat Bugzilla – Bug 848123
rebalance of distributed volume sets identical hash intervals for all directories
Last modified: 2013-12-08 20:32:58 EST
Description of problem: rebalancing a distributed volume assigns identical hash intervals to directories, thus, all files with the same filename end up on the same brick Version-Release number of selected component (if applicable): 3.3.0 How reproducible: always Steps to Reproduce: 1. create a distributed volume with one brick 2. create some directories on the volume 3. add one (or more) bricks to the volume 4. start a rebalance Actual results: all directories on a given brick have the same hash intervals assigned Expected results: rotated hash intervals for directories on a given brick as they are assigned when the directory is created in a volume which has multiple bricks from the beginning Additional info: - previous discussion on mailing list: http://gluster.org/pipermail/gluster-users/2012-August/011130.html - if you fill every directory with a common set of files before extending the volume, all files of a given name will end up on one brick after rebalancing; that's how we noticed the problem, but in fact this is just consistent with the assignment of hash intervals to directories during rebalancing
Can you please provide the o/p of: getfattr -n trusted.glusterfs.dht -e hex </path/to/bricks> ?
Created attachment 604409 [details] trusted.glusterfs.dht attributes for brick directories listing of trusted.glusterfs.dht attributes for brick directories and the directories containing the data files
The reason why you see such kind of distribution is: 1. You started off with a single brick volume, and hence the complete hash is the single brick. 2. You added 2 brick, and issued rebalance. Now during rewriting of layout (rebalancing), layout's are calculated to reduce the amount data migrated. So, overlaps are considered. In your scenario, 1st brick always got the start range, and others the remaining in a round robin. With regards, Shishir
(In reply to comment #3) > 1. You started off with a single brick volume, and hence the complete hash > is the single brick. clear > 2. You added 2 brick, and issued rebalance. Now during rewriting of layout > (rebalancing), layout's are calculated to reduce the amount data migrated. > So, overlaps are considered. The overlap should be identical if the hash intervals were swapped between brick 1 and 2. > In your scenario, 1st brick always got the start range, and others the > remaining in a round robin. And that's the problem, why does the 1st brick always get the start range. Cheers, Jochen
*** This bug has been marked as a duplicate of bug 853258 ***