Bug 2108182

Summary: Actual disk size is bigger when converting block disk from raw_Preallocated to cow_sparse
Product: [oVirt] ovirt-engine Reporter: sshmulev
Component: BLL.StorageAssignee: Benny Zlotnik <bzlotnik>
Status: CLOSED NEXTRELEASE QA Contact: sshmulev
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.5.2CC: ahadas, bugs, bzlotnik, dfodor, michal.skrivanek, sfishbai
Target Milestone: ovirt-4.5.3Keywords: Automation, ZStream
Target Release: ---Flags: pm-rhel: ovirt-4.5?
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: 2022-09-19 14:31:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description sshmulev 2022-07-18 14:19:17 UTC
Description of problem:
When converting from Raw-preallocated-incremental_disabled to Cow-Thin-incremental_enabled, the actual size becomes bigger than the provisioned size.
When converting to a Thin disk we expect the size to be smaller than the actual size, but instead, the disk gets bigger after the disk convert.
This happens only on block storage type.


Version-Release number of selected component (if applicable):
ovirt-engine-4.5.1.3-654.af4ac851f145.33.el8ev.noarch
vdsm-4.50.2-1.el8ev

How reproducible:
100%

Steps to Reproduce:
1. Create a disk with API request:
{{ENV_Hostname}}/api/disks

<disk>
  <storage_domains>
    <storage_domain id="{{ISCSI_SD}}"/>
  </storage_domains>
  <name>ISCSI_Raw-Preallocated-Disabled</name>
  <provisioned_size>1073741824</provisioned_size>
  <format>raw</format>
  <sparse>false</sparse>
  <backup>None</backup>
</disk>

2. wait until the disk is in ok status and convert with the following request
{{ENV_Hostname}}/api/disks/{{ISCSI_Raw-Preallocated-Disabled}}/convert

<action>
    <disk>
        <format>cow</format>
        <sparse>true</sparse>
        <backup>incremental</backup>
    </disk>
</action>


Actual results:
Before the convert:
<actual_size>1073741824</actual_size>
<provisioned_size>1073741824</provisioned_size>

After the disk convert:
<actual_size>1207959552</actual_size>
<provisioned_size>1073741824</provisioned_size>

Expected results:
After the diskconvert:
The actual size should be smaller than the provisioned size since the disk was converted when it was empty.

Additional info:
Actually, this bug fix (https://bugzilla.redhat.com/show_bug.cgi?id=2076047) leads to this situation 
In order to avoid this, I suggest two steps of conversion in such a scenario.
For example: First, convert the format type and then the allocation policy from preallocated to Sparse.

Comment 1 Arik 2022-07-19 06:38:12 UTC
(In reply to sshmulev from comment #0)
> Expected results:
> After the diskconvert:
> The actual size should be smaller than the provisioned size since the disk
> was converted when it was empty.

Benny, is it a fair assumption? note that the disk was raw+preallocated - does qemu-img check if the blocks are empty or not? I doubt it and if it doesn't then having actual size > provisioned size (due to the metadata) makes sense..

Comment 2 Michal Skrivanek 2022-07-19 07:11:24 UTC
i guess you can sparsify before/after?

Comment 3 Arik 2022-07-19 07:42:26 UTC
(In reply to Michal Skrivanek from comment #2)
> i guess you can sparsify before/after?

Right, Benny and I discussed that offline and concluded we'll add that to the documentation of the API that sparsify can be executed afterwards in this case

Comment 4 Casper (RHV QE bot) 2022-09-19 14:31:46 UTC
This bug has low overall severity and is not going to be further verified by QE. If you believe special care is required, feel free to properly align relevant severity, flags and keywords to raise PM_Score or use one of the Bumps ('PrioBumpField', 'PrioBumpGSS', 'PrioBumpPM', 'PrioBumpQA') in Keywords to raise it's PM_Score above verification threashold (1000).

Comment 5 Casper (RHV QE bot) 2022-09-19 14:31:47 UTC
This bug has low overall severity and passed an automated regression suite, and is not going to be further verified by QE. If you believe special care is required, feel free to re-open to ON_QA status.

Comment 6 sshmulev 2022-11-14 12:57:42 UTC
It was suggested to convert this case into two separate converts: First, convert the format type and then the allocation policy from preallocated to Sparse.

We made this WA to our automation according to this suggestion, since this issue was not closed for the next release.
Many builds have passed successfully, but lately, we have seen an issue with this type of conversion: The issue is the size of the disk after the convert



The disk is: raw, sparse-False
Convert disks format + allocation policy.
convert supposed to be :
raw/sparse False ->  cow/sparse True
This one succeeded, the disk changed the types of format and allocation policy, although the size is not as expected for sparse:
actual_size after convert should be smaller than the provisioned_size. In this case, it is bigger, why?

Before convert:
<actual_size>5368709120</actual_size>
<sparse>false</sparse>
<format>raw</format>
<provisioned_size>5368709120</provisioned_size>


After convert:
<actual_size>6039797760</actual_size>
<sparse>true</sparse>
<format>cow</format>
<provisioned_size>5369757696</provisioned_size>