Description of problem: At the moment the volume type (preallocated/sparse) has very little meaning. In fact: - if format is cow then type is always sparse - if the storage domain is block and format is raw then type is always prellocated the only case where we believe it matters is on file domains and raw format, but: - some appliances discard zero writes (which means that even if we spend time and bandwidth with dd trying to write zeroes, they get discarded and the file will remain sparse. This happens on netapp and nexenta, not sure what specific models/versions, but it's irrelevant at this point) - preallocation/sparseness is a state of the file, which means that can be easily queried with stat(2) and reported to engine - maintaining preallocation on disk extension is risky and error prone especially if the vm is running (and it will probably be extremely hard to maintain with sdm; nothing is impossible but this is next to it) The situation could change in the future with fallocate(1) that was specifically designed to preallocate or deallocate space to a file. Sadly at the moment it's not supported by nfs (even if the remote filesystem already supports it) and it will be coming in nfs 4.2 (or 4.1, anyway it's not available now). So I think that we should try to maintain the type (preallocated/sparse) as much coherent as it's possible (in order to keep the domain metadata backward compatible) on the vdsm side but at the same time we should phase it out from engine and APIs. When fallocate will be available on nfs then engine will be able to decide at any time (e.g. on volume creation, on user request, on automatic policy, etc.) to issue the allocateVolume request. At any time engine can discover the allocation ratio of a volume using getVolumeInfo (apparentsize/truesize). This is what we currently support: RAW (preallocated) | RAW (sparse) | COW (sparse) ------------------------------------------------------- block | X | | X ------------------------------------------------------- file | X | X | X Dropping the useless preallocated case on file domains we would support: RAW (preallocated) | RAW (sparse) | COW (sparse) ------------------------------------------------------- block | X | | X ------------------------------------------------------- file | | X | X where in fact the preallocated and sparse types would lose all their meaning: in fact COW is always sparse by definition and in block and file domains RAW volumes are either preallocated or sparse by the virtue of their storage nature.
"The situation could change in the future with fallocate(1) that was specifically designed to preallocate or deallocate space to a file. Sadly at the moment it's not supported by nfs (even if the remote filesystem already supports it) and it will be coming in nfs 4.2 (or 4.1, anyway it's not available now)." This is in the NFSv4.2 protocol draft. RHEL7 has some support for NFSv4.2 (for security labeling), and it should be easy enough to drop in fallocate support when the protocol is agreed upon, but the details seem to still be under discussion so I'm not sure when that will be. Agreed that the manual "preallocation" doesn't seem very useful here. But perhaps a disk filesystem expert could confirm.
I discovered that we currently have already two "bugs" (at least) where we are not able maintain and guarantee preallocation of file volumes. Both mergeSnapshot and copyCollapsed were relying (in the most common case of taking a cow chain and converting it to raw) on qemu-img, therefore generating a sparse raw volumes in all cases. Reference: http://gerrit.ovirt.org/26921
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
*** Bug 1282654 has been marked as a duplicate of this bug. ***
This is an important step in the route of migrating away from storage domains. After discussing with Yaniv L, moving back to 4.2.
Can you please provide more details to how this can assist with the migration away from the storage domain?
(In reply to Yaniv Lavi from comment #10) > Can you please provide more details to how this can assist with the > migration away from the storage domain? These are meaningless settings (which you can't control anyway, not without controlling the format - which you already do explicitly), which we won't be able to migrate to a lun based solution.
With the introduction of proper preallocaiton in RHV 4.2, I'm not sure we'd want to go down this route.
(In reply to Allon Mureinik from comment #12) > With the introduction of proper preallocaiton in RHV 4.2, I'm not sure we'd > want to go down this route. Then closing.