Bug 1842254

Summary: [NooBaa] Compression stats do not add up when compression id disabled
Product: [Red Hat Storage] Red Hat OpenShift Container Storage Reporter: Ben Eli <belimele>
Component: Multi-Cloud Object GatewayAssignee: Romy Ayalon <rayalon>
Status: CLOSED ERRATA QA Contact: Ben Eli <belimele>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.4CC: assingh, ebenahar, etamir, muagarwa, nbecker, ocs-bugs
Target Milestone: ---   
Target Release: OCS 4.6.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: v4.6.0-113.ci Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-12-17 06:22:30 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:

Description Ben Eli 2020-05-31 11:36:21 UTC
Description of problem (please be detailed as possible and provide log
snippests):
I'm uploading the same object three times to the same bucket. However, when I enter the object's overview panel, "Original Size" and "Actual Used Storage" are the same size for all three copies - even though "Raw Usage" and "Data Optimization" stats are correct.

Another example - I upload enwik8 which should be compressed to about 54MB/s with Snappy (which it did) and three duplicate files (each weighing 43MB).
NooBaa claims it reduced 128 MB, while it should be 140 - 43*2 (duplicate files) + 54 (enwik8 post-compression)

Version of all relevant components (if applicable):
NooBaa 5.4.0-93d9738
OCS 4.4.0-428.ci 
OCP 4.4.0-0.nightly-2020-05-25-020741

Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?
No

Is there any workaround available to the best of your knowledge?
No

Rate from 1 - 5 the complexity of the scenario you performed that caused this
bug (1 - very simple, 5 - very complex)?
2

Can this issue reproducible?
Yes

Can this issue reproduce from the UI?
No

If this is a regression, please provide more details to justify this:


Steps to Reproduce:
1. Create a bucket called `duplicates`, upload the same object three times under different names
2. Create another bucket called `compressed-and-duplicates`, upload the same object three times, and upload an `enwik8` test file
3. See the phenomena described above


Actual results:
Stats aren't right/don't add up

Expected results:
Stats are right and the numbers do add up

Additional info:

Comment 2 Nimrod Becker 2020-06-04 16:50:24 UTC
@ben , regarding the first example, was the file binary data ? or compressable one ?

In the object screen you are shown compression, and not dedup. Dedup is shown only in the bucket level. Thus, if the obj is not compressable the sizes would be the same in the object view

Comment 7 Ben Eli 2020-10-05 11:52:06 UTC
Romy - you're right, thanks for the correction.
Your calculations seem to be the right ones, and also seem to make sense in this context, thus leaving only the bug that shows 100% compression.

Nimrod - also, makes sense. Thanks for the explanation.

Comment 10 Ben Eli 2020-10-20 12:45:13 UTC
I disabled compression by following the knowledgebase article (https://access.redhat.com/articles/5469161), created a new bucket, and uploaded enwik8 to it.
The file was not compressed, and the data optimization graph stayed at 0%.

Verified
ocs-operator.v4.6.0-134.ci
OCP 4.6.0-0.nightly-2020-10-17-040148

Comment 13 errata-xmlrpc 2020-12-17 06:22:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: Red Hat OpenShift Container Storage 4.6.0 security, bug fix, enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:5605