Bug 848123 - rebalance of distributed volume sets identical hash intervals for all directories
rebalance of distributed volume sets identical hash intervals for all directo...
Status: CLOSED DUPLICATE of bug 853258
Product: GlusterFS
Classification: Community
Component: distribute (Show other bugs)
3.3.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: shishir gowda
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-14 12:57 EDT by Jochen Klein
Modified: 2013-12-08 20:32 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-26 00:27:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
trusted.glusterfs.dht attributes for brick directories (100.13 KB, text/plain)
2012-08-14 15:01 EDT, Jochen Klein
no flags Details

  None (edit)
Description Jochen Klein 2012-08-14 12:57:31 EDT
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 14:11:26 EDT
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 15:01:57 EDT
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 06:22:11 EDT
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 06:55:51 EDT
(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 00:27:16 EDT

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

Note You need to log in before you can comment on or make changes to this bug.