Description of problem: A new sparsify option was added in 4.1: https://bugzilla.redhat.com/show_bug.cgi?id=734120 This option provides the ability to re claim previously used disk space of the guest in case guest's disk is thin provisioned. The option will have no effect on pre allocated disks and there for is redundant for that case. Currently the option is available to use on any disk, and will just report success even if nothing has actually been done on the disk. This has no negative effect but is just awkward and misleading so I suggest to disable the option. Either gray out the button in case the disk is pre allocated. Or fail the command with a relevant error msg. Version-Release number of selected component (if applicable): ovirt-engine-4.1.0-0.4.master.20170116141310.gita30debd.el7.centos.noarch How reproducible: always Steps to Reproduce: 1. Create a vm with a pre allocated disk on iscsi SD. 2. Create some files on the vm and then delete them. 3. Stop the vm. 4. Sparsify vm's disk (under disk sub tab of vm tab) Actual results: Action reports success, at no point does the actual disk size change, as it was all allocated in advance. Expected results: Fail with message: 'Cannot sparsify disk {name_of_disk}, disk space was pre allocated' or something of that sort. Additional info:
Why doesn't it work on pre-allocated disks? It should, unless they have 'wipe-after-delete' checked, in which case it gets a bit more complicated (for security reasons, we don't want to simply discard, but ensure it is wiped before that. Some arrays support it, some don't - we'll complete this work in 4.1.z). Idan - thoughts?
Yes, actually it doesn't matter if the disk is thinly provisioned or pre-allocated. If I understood it correctly, virt-sparsify --in-place adds the disk's mount options the 'discard' option and calls 'fstrim /', which is exactly one of the options to reclaim space using the "Pass Discard" option of a vm disk, only that in the case of virt-sparsify you also need to shut down the vm. Two questions that should be asked are: 1. Does the underlying storage support discard? What happens if it doesn't? 2. Does the underlying storage support the property that discard zeroes the data? If not, we cannot allow running virt-sparsify when wipe after delete is enabled. From what I've seen in the code, these validations are not made prior to the call to virt-sparsify, even though the final outcome is the same as in Pass Discard, where we do check these things. Shmuel, am I missing something here? Can you please clarify?
(In reply to Yaniv Kaul from comment #1) > Why doesn't it work on pre-allocated disks? It works on pre-allocated disks, but I doubt it is justified for this case. User chooses pre-allocated option if she needs better performance, because no additional allocation and no fragmentation will occur when the disk is used. Deallocating some clusters as result of sparsification will overturn this advantage. If user wants to save space at cost of some performance decrease, she will select thin-provisioned option. So I would disable sparsify for pre-allocated disks.
(In reply to Idan Shaby from comment #2) > Two questions that should be asked are: > 1. Does the underlying storage support discard? What happens if it doesn't? Nothing will happen. Like in any other case when no blocks can be discarded. > 2. Does the underlying storage support the property that discard zeroes the > data? If not, we cannot allow running virt-sparsify when wipe after delete > is enabled. I don't check this currently. But yes, need to check this.
Please see BZ 1415491 to track this bug.
ok, so just disable the sparsify for preallocated disk. Since it is a new feature, targeting 4.1.1
Verified with rhevm-4.1.1.2-0.1.el7.noarch. Sparsify action is disabled when the disk is pre allocated (sparse=False).