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:
@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
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.
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
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