Bug 808991

Summary: 'volume rebalance force' says rebalance started successfully but status says "rebalance not started"
Product: [Community] GlusterFS Reporter: M S Vishwanath Bhat <vbhat>
Component: cliAssignee: shishir gowda <sgowda>
Status: CLOSED UPSTREAM QA Contact:
Severity: low Docs Contact:
Priority: unspecified    
Version: pre-releaseCC: gluster-bugs, mzywusko, nbalacha, nsathyan, sgowda, wangqg1
Target Milestone: ---Flags: nbalacha: needinfo? (wangqg1)
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-05 10:14:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description M S Vishwanath Bhat 2012-04-02 07:30:27 UTC
Description of problem:
gluster volume rebalance <volname> force (without start) says rebalance started successfully on said volume. But after that gluster rebalance status says rebalance not started.

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

How reproducible:
Consistent

Steps to Reproduce:
1. Create and start a single node distribute volume.
2. Create some data on the mountpoint and then add one more brick to the volume.
3. Now run 'gluster v reb <volname> force' (without start keyword)
4. It says 'rebalance started'. Now run rebalance status.
  
Actual results:

[root@QA-25 /]# gluster v reb hosdu force
Starting rebalance on volume hosdu has been successful
[root@QA-25 /]# gluster v reb hosdu status
                                    Node Rebalanced-files          size       scanned         status
                               ---------      -----------   -----------   -----------   ------------
    9c3b029d-ed4a-4e92-b580-7e6cac951d67                0            0            0   not started
    4237f3b2-04b3-41d9-9080-ba51fb884fdd                0            0            0   not started
    b9186b17-bf82-4266-b689-9ebe5474d10e                0            0            0   not started
    62dc2b19-cce5-4e41-a45e-bf36411a4da4                0            0            0   not started

[root@QA-25 /]# gluster v reb hosdu status
                                    Node Rebalanced-files          size       scanned         status
                               ---------      -----------   -----------   -----------   ------------
    9c3b029d-ed4a-4e92-b580-7e6cac951d67                0            0            0   not started
    4237f3b2-04b3-41d9-9080-ba51fb884fdd                0            0            0   not started
    b9186b17-bf82-4266-b689-9ebe5474d10e                0            0            0   not started
    62dc2b19-cce5-4e41-a45e-bf36411a4da4                0            0            0   not started

[root@QA-25 /]# 

Expected results:
Ideally it should have one of the following behavior. 
1. rebalance command without the start keyword should not start the rebalance and should display the same when that command is issued.
OR
2. Since there is no other rebalance operations which has force keyword, rebalance can be started. But in that case the rebalance status should output the proper results.

Comment 1 shishir gowda 2012-04-02 09:16:01 UTC
Can you please archive glusterd/rebalance process logs?

Comment 2 Anand Avati 2012-04-02 18:29:44 UTC
CHANGE: http://review.gluster.com/3064 (cli/rebalance: Fix parse error for volume rebalance cmd) merged in master by Vijay Bellur (vijay)

Comment 3 M S Vishwanath Bhat 2012-04-05 10:14:00 UTC
Now rebalance force without the start gives me usage message.

[root@QA-29 ~]# gluster volume rebalance hosdu force
Usage: volume rebalance <VOLNAME> [fix-layout] {start|stop|status} [force]

Comment 4 Qigang 2019-05-10 06:45:31 UTC
The same behavior observed with 3.12. Gluster log shows fix-layout is being done but the speed is really slow. It looks like it may take months to finish fix-layout. Is there any way to fix the status mismatch?

Comment 5 Nithya Balachandran 2019-05-10 06:53:08 UTC
(In reply to Qigang from comment #4)
> The same behavior observed with 3.12. Gluster log shows fix-layout is being
> done but the speed is really slow. It looks like it may take months to
> finish fix-layout. Is there any way to fix the status mismatch?

This BZ has been closed. Please file a new one with the required information.