Description of problem: Extend of the raw sparse disk (thin provisioned without incremental backup) is ignored Version-Release number of selected component (if applicable): vdsm-4.50.3.7-1.el8ev.x86_64 How reproducible: 100% Steps to Reproduce: 1. reproduced on gluster so far, did not check other file-based 2. Create a thin provisioned disk without incremental backup on gluster sd 3. try to extend the disk in the UI Actual results: update operation finished successfully, however disk is not extended Expected results: disk is extended Additional info: issue is only reproduced on vdsm-4.50.3.7-1 everything is working fine on vdsm-4.50.3.6-1.el8ev.x86_64 so it looks like regression will attach debug logs asap.
i do not know why bellow was not logged in debug log level: /usr/lib/python3.6/site-packages/vdsm/storage/volume.py ~~~ if self.getType() == sc.SPARSE_VOL: self.log.debug("skipping sparse size extension for volume %s to " "capacity %s", self.volUUID, new_capacity) return ~~~ however when i set it to info i could see that it is skipped : ~~~ 2023-05-26 10:34:00,253+0000 INFO (tasks/9) [storage.volume] Test, new_capacity is 13958643712 (volume:1386) 2023-05-26 10:34:00,269+0000 INFO (tasks/9) [storage.volume] Test, voltype = 2 (volume:1391) 2023-05-26 10:34:00,269+0000 INFO (tasks/9) [storage.volume] skipping sparse size extension for volume 107c8b50-e537-4188-95e7-83d12e647d8f to capacity 13958643712 (volume:1394) ~~~ I do already see that it is changed in later version to: ~~~ volFormat = self.getFormat() if volFormat == sc.COW_FORMAT: self.log.debug("skipping cow size extension for volume %s to " "capacity %s", self.volUUID, new_capacity) return elif volFormat != sc.RAW_FORMAT: raise se.IncorrectFormat(self.volUUID) ~~~ I have tested it and it is working fine to extend raw sparse volume
The problem with the logs sounds indeed a bit weird... The issue with the resize for raw+sparse, is actually a regression, yes. I have been able to reproduce the issue with a file volume test. We had a misunderstanding with the extendSize() logic during the previous review, and a coverage gap in the tests. I will post a patch that hopefully will deal with both issues.
Verified, the file disk (nfs sd) is extended ovirt-engine-4.5.3.9-0.zstream.20230605102913.git3bfac2e0eac.el8.noarch vdsm-4.50.3.8-1.el8ev.x86_64
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 (Important: Red Hat Virtualization security and bug fix 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-2023:3771