During deletion of snapshot vdsm creates a temporary zero filled file on disk. E.g. /usr/bin/dd if=/dev/zero of=/rhev/data-center/.../a7647e33-daf8-42d1-b7c1-e3e396725cd9_MERGE bs=1048576 seek=0 skip=0 conv=notrunc count=15360 oflag=direct On an NFS based datacenter that can be optimized if the empty file is created with the sparse option. The filesystem on the NFS storage needs to support that feature but that should not matter for the commands to be issued. Evaluation of current performance: root@hypervisor:/rhev/...# dd if=/dev/zero of=mst_zero bs=1M count=10000 10000+0 blocks in 10000+0 blocks out 10485760000 Bytes (10 GB) copied, 30,5009 s, 344 MB/s root@hypervisor:/rhev/...# du -m mst_zero 10001 mst_zero Compared to optimized file creation with sparse file: root@hypervisor:/rhev/...# dd if=/dev/zero bs=1M count=10000 | cp --sparse=always /proc/self/fd/0 mst_zero 10000+0 blocks in 10000+0 blocks out 10485760000 Bytes (10 GB) copied, 5,44402 s, 1,9 GB/s root@hypervisor:/rhev/...# du -m mst_zero 0 mst_zero The above numbers have been collected on a linux NFS server. Hypervisor nodes are attached with NFS over IPoIB.
Looking further at the snapshot deletion process the dd command seems to be even more confusing. For the analysis I have taken a VM with a 26GB thin provisioned disk. On the datastore it occupies round about 21GB. The systems acts the following way: 1) create a 26GB fully allocated zeroed file called /rhev/....MERGE with dd command. du reveals that it does not use thin provisioning 2) afterwards call "qemu-img convert" with target file /rhev/....MERGE. Interesting enough this will immediately wipe the previously created file. It will start with an empty file and end up with the 21GB used space as before. Leaves me clueless.
Fede, any thoughts?
This is an automated message. This Bugzilla report has been opened on a version which is not maintained anymore. Please check if this bug is still relevant in oVirt 3.5.4. If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution) If it's an RFE please update the version to 4.0 if still relevant.
This is an automated message. This Bugzilla report has been opened on a version which is not maintained anymore. Please check if this bug is still relevant in oVirt 3.5.4 and reopen if still an issue.