Bug 1293593

Summary: [RFE] Values in scrub status output expect error count and corrupted objects gets reset when node reboots or glusterd restarts
Product: Red Hat Gluster Storage Reporter: RamaKasturi <knarra>
Component: bitrotAssignee: Venky Shankar <vshankar>
Status: CLOSED NOTABUG QA Contact: RamaKasturi <knarra>
Severity: urgent Docs Contact:
Priority: urgent    
Version: rhgs-3.1CC: byarlaga, knarra, nsathyan, rhs-bugs, storage-qa-internal, vagarwal
Target Milestone: ---Keywords: FutureFeature, ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-05 13:12:37 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:

Description RamaKasturi 2015-12-22 10:15:04 UTC
Description of problem:
vlaues for Number of Scrubbed files, Number of Unsigned files, Last completed scrub time and Duration of last scrub gets reset to default value when glusterd or bitd or one of the node reboots.

Version-Release number of selected component (if applicable):
glusterfs-3.7.5-12.el7rhgs.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Install latest glusterfs build.
2. Now wait for scrubber to scrub some of the files so that scrub status gives the output.
3. Now either restart glusterd / bitd / one of the nodes in the cluster.

Actual results:
I see that all the values for Number of Scrubbed files, Number of Unsigned files, Last completed scrub time and Duration of last scrub gets reset to default

Expected results:
All the values for  Number of Scrubbed files, Number of Unsigned files, Last completed scrub time and Duration of last scrub gets reset to default when node / glusterd reboots.

Additional info:

Comment 4 RamaKasturi 2015-12-28 09:13:44 UTC
I am okay to mark this for 3.1.3. But i feel  that this has to go as known issue.

Comment 5 Venky Shankar 2015-12-28 09:30:09 UTC
(In reply to RamaKasturi from comment #4)
> I am okay to mark this for 3.1.3. But i feel  that this has to go as known
> issue.

I'm thinking if we can just stick to showing the corrupted object list along with the corrupted object count, i.e. the statistics which are not accurate as of now are *not shown*.

Also, I would wait till the fix goes upstream (we have already started some work on it) to call out which release would this make it to.

Comment 6 RamaKasturi 2015-12-28 09:37:08 UTC
(In reply to Venky Shankar from comment #5)
> (In reply to RamaKasturi from comment #4)
> > I am okay to mark this for 3.1.3. But i feel  that this has to go as known
> > issue.
> 
> I'm thinking if we can just stick to showing the corrupted object list along
> with the corrupted object count, i.e. the statistics which are not accurate
> as of now are *not shown*.
> 
> Also, I would wait till the fix goes upstream (we have already started some
> work on it) to call out which release would this make it to.

venky, are you saying that we will not show any other values other than error count and corrupted objects list in the scrub status output?