Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1451434

Summary:	Use a bitmap to store local node info instead of conf->local_nodeuuids[i].uuids
Product:	[Community] GlusterFS	Reporter:	Nithya Balachandran <nbalacha>
Component:	distribute	Assignee:	Nithya Balachandran <nbalacha>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	mainline	CC:	bugs, srangana
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	glusterfs-3.13.0	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1500472 (view as bug list)		Environment:
Last Closed:	2017-12-08 17:33:42 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:
Bug Depends On:
Bug Blocks:	1500472

Description Nithya Balachandran 2017-05-16 15:59:20 UTC

Description of problem:
From Jeff Darcy's review:

"Do we really need to gf_uuid_compare here?  What if, instead of storing the complete list of UUIDs for each replica set, we instead stored a bitmap of which replicas were local?  Then this comparison would look more like this.
   if ((1 << index) && conf->local_replicas_mask)
Because the bitmap would be more compact, this might also ease worries about dynamic memory allocation etc."

...

"I'm just keenly aware that this is likely to be a frequently executed code path - there could be millions of files to be rebalance - so extra loops need to be carefully considered.  If they're justified, great, so long as they're considered."

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Worker Ant 2017-07-21 11:15:49 UTC

REVIEW: https://review.gluster.org/17851 (cluster/dht: Don't store the entire uuid for subvols WIP) posted (#1) for review on master by N Balachandran (nbalacha)

Comment 2 Worker Ant 2017-09-15 06:07:26 UTC

REVIEW: https://review.gluster.org/17851 (cluster/dht: Don't store the entire uuid for subvols) posted (#2) for review on master by N Balachandran (nbalacha)

Comment 3 Worker Ant 2017-09-15 16:20:07 UTC

REVIEW: https://review.gluster.org/17851 (cluster/dht: Don't store the entire uuid for subvols) posted (#3) for review on master by N Balachandran (nbalacha)

Comment 4 Worker Ant 2017-10-03 14:00:31 UTC

REVIEW: https://review.gluster.org/17851 (cluster/dht: Don't store the entire uuid for subvols) posted (#4) for review on master by N Balachandran (nbalacha)

Comment 5 Worker Ant 2017-10-04 07:45:00 UTC

REVIEW: https://review.gluster.org/17851 (cluster/dht: Don't store the entire uuid for subvols) posted (#5) for review on master by N Balachandran (nbalacha)

Comment 6 Worker Ant 2017-10-05 12:39:36 UTC

REVIEW: https://review.gluster.org/17851 (cluster/dht: Don't store the entire uuid for subvols) posted (#6) for review on master by N Balachandran (nbalacha)

Comment 7 Worker Ant 2017-10-10 08:58:43 UTC

COMMIT: https://review.gluster.org/17851 committed in master by Raghavendra G (rgowdapp) 
------
commit c4a608799a577a4f38139f6bb8a47da8efb0fec3
Author: N Balachandran <nbalacha>
Date:   Fri Jul 21 16:38:14 2017 +0530

    cluster/dht: Don't store the entire uuid for subvols
    
    Comparing the uuid string of the local node against that stored in the
    local_subvol information is inefficient, especially as it is
    done for every file to be migrated. The code has now been changed
    to set the value of info to 1 if the nodeuuid is that of the node
    making the comparison so this becomes an integer comparison.
    
    Change-Id: I7491d59caad3b71dbf5facc94dcde0cd53962775
    BUG: 1451434
    Signed-off-by: N Balachandran <nbalacha>

Comment 8 Shyamsundar 2017-12-08 17:33:42 UTC

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.13.0, please open a new bug report.

glusterfs-3.13.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://lists.gluster.org/pipermail/announce/2017-December/000087.html
[2] https://www.gluster.org/pipermail/gluster-users/