[ovirt-users] Re: Q: Sparsify/fstrim don't reduce actual disk image size
On Wed, Apr 7, 2021 at 5:36 PM Andrei Verovski <andreil1(a)starlett.lv> wrote:
Hi !
I have VM (under oVirt) with single disk thin provision (~600 GB)
I guess you are using block storage?
running NextCloud on Debian 9.
Right now VM HD is almost empty. Unfortunately, it occupies 584 GB (virtual size = 600
GB)
All partition (except swap and boot) are EXT4 with discard option.
You don't need to use discard mount option. fstrim works without it.
in oVirt “enable discard = on”.
# fstrim -av runs successfully:
/var: 477.6 GiB (512851144704 bytes) trimmed on /dev/mapper/vg--system-lv4--data
/boot: 853.8 MiB (895229952 bytes) trimmed on /dev/mapper/vg--system-lv2--boot
/: 88.4 GiB (94888611840 bytes) trimmed on /dev/mapper/vg--system-lv3—sys
When fstrim runs again, it trims zero. I even run “Sparsify” in oVirt. Unfortunately,
actual size is still 584 GB.
Here is /etc/fstab
/dev/mapper/vg--system-lv3--sys / ext4
discard,noatime,nodiratime,errors=remount-ro 0 1
/dev/mapper/vg--system-lv2--boot /boot ext2 defaults 0 2
/dev/mapper/vg--system-lv4--data /var ext4 discard,noatime,nodiratime 0
2
/dev/mapper/vg--system-lv1--swap none swap sw 0 0
When disk was partitioned/formatted, swap and boot were created first and positioned at
the beginning.
What is wrong here? Is it possible to fix all this ?
Discarding data mark the areas in the qcow2 image as zero, but it does not move
actual data around (which is very slow). So if the clusters were at
the end of the
image they remain there, and the actual file size is the same.
The only way to reclaim the space is:
1. sparsify disk - must be done *before* copying the disk.
2. move this to another storage domain
3. move disk back to the original storage domain
We may have an easier and more efficient way in the future that
works with single storage domain, but it will have to copy the
entire disk. If the disk is really mostly empty it should be fast.
Nir