Bug 808991 - 'volume rebalance force' says rebalance started successfully but status says "rebalance not started"
Summary: 'volume rebalance force' says rebalance started successfully but status says ...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: GlusterFS
Classification: Community
Component: cli
Version: pre-release
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: shishir gowda
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-02 07:30 UTC by M S Vishwanath Bhat
Modified: 2023-09-14 01:28 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-05 10:14:00 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

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.

Comment 6 Red Hat Bugzilla 2023-09-14 01:28:19 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


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