Bug 848123

Summary: rebalance of distributed volume sets identical hash intervals for all directories
Product: [Community] GlusterFS Reporter: Jochen Klein <jochen_klein>
Component: distributeAssignee: shishir gowda <sgowda>
Status: CLOSED DUPLICATE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.3.0CC: gluster-bugs, nsathyan, vbellur
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-26 04:27:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
trusted.glusterfs.dht attributes for brick directories none

Description Jochen Klein 2012-08-14 16:57:31 UTC 
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
Comment 1 Vijay Bellur 2012-08-14 18:11:26 UTC 
Can you please provide the o/p of:

getfattr -n trusted.glusterfs.dht -e hex </path/to/bricks> ?
Comment 2 Jochen Klein 2012-08-14 19:01:57 UTC 
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
Comment 3 shishir gowda 2012-08-20 10:22:11 UTC 
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
Comment 4 Jochen Klein 2012-08-20 10:55:51 UTC 
(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
Comment 5 shishir gowda 2012-09-26 04:27:16 UTC 

*** This bug has been marked as a duplicate of bug 853258 ***