| Summary: | [Bitrot]: 'Total scrubbed files' count off-the-mark, by the number of corruptions detected | ||
|---|---|---|---|
| Product: | Red Hat Gluster Storage | Reporter: | Sweta Anandpara <sanandpa> |
| Component: | bitrot | Assignee: | Bug Updates Notification Mailing List <rhs-bugs> |
| Status: | CLOSED DEFERRED | QA Contact: | Sweta Anandpara <sanandpa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rhgs-3.2 | CC: | amukherj, atumball, rhs-bugs, sanandpa, storage-qa-internal |
| Target Milestone: | --- | Keywords: | ZStream |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-11 10:15: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
Sweta Anandpara
2016-10-03 11:37:51 UTC
Will update in this space with the exact sequence of steps, to reproduce it. Analysis:
This is not actually a bug. A little more understanding of scrub status helps here.
Number of Scrubbed files :
It represents the number of files the scrubber actuallyscrubbed in the scrub cycle. Scrub meaning, calculation of checksum in memory and compared with on disk and verifying whether it's corrupted or not. It does not count if the file is already bad and if signing is not happened to scrub.
Number of Skipped files:
It counts number of files for which signing did not happen at the time of scrubbing. It doesn't consider bad files.
Considering above scenarios, let's analyse the possible outputs. Let's say
4 files are present as in this bug.
1. One file is corrupted. Assume signing is done for all files.
> On first scrub run of file corruption.
Number of scrubbed files: 4
Number of skipped files: 0
Error: 1
> On second scrub run while the file is still corrupted.
Number of scrubbed files: 3
Number of skipped files: 0
Error: 1
In second run, it didn't actually scrub the bad file, hence the count is 3
and is correct.
2. Assume the corrupted file has one hardlink.
> On first scrub run of file corruption.
Number of scrubbed files: 3
Number of skipped files: 0
Error: 1
This is because, while scrubbing hardlink, it finds it bad and doesn't scrub it.
> On second and further run while the file is still corrupted.
Number of scrubbed files: 2
Number of skipped files: 0
Error: 1
Error count is 1 because it doesn't counting hardlinks.
Please test this again with above understanding and close this as not a bug if the counts match as per above definition.
Partly agree with comment 3. The real sense/meaning of scrub might be what is mentioned. It somehow doesn't seem to be intuitive, from the end user perspective. Nor does it feel simple enough for the end user to understand. The 'Number of scrubbed files', IF it is anything lesser than the total number of files, gives the impression that file(s) was/were skipped. Then the user would expect that count to be present in the 'skipped files', which will not really reflect that. And it would mislead one to think that a file was neither scrubbed, nor skipped. Either ways, it would be less hassle free if the 'scrubbed files' count becomes synonymous to 'total /considered/ files' count. Additional testing was done to verify if the behaviour has been the same even in the past releases. The very first scrub cycle shows the correct count of 'files scrubbed'. Every subsequent cycle shows the #files scrubbed to be reduced by the number of corruptions detected (in that particular node). This behaviour inspite of being present from before, has come to the fore after having a 'scrub ondemand' option. Marking as deferred! 2 reasons! This bug was not a blocker in last 2 years, BitRot is not a focus right now, and we haven't faced any customer issues on this component! Reopen if anything changes, or component becomes important! |