[ovirt-users] Re: Q: Sparsify/fstrim don't reduce actual disk image size
Hi,
Many thanks, its worked ! Actual size shrunk from 584 to 9 GB, now I have space to
backup.
Is there any guidelines how to format QCOW2 images (for Linux) so they can be shrunk in an
efficient way?
With this NextCloud/Collabora LVM I did in the following order:
swap
ext2 boot
ext4 root
ext4 var (large, for data, all cloud data stored here)
Ext4 partitions on LVM.
Or this is not predictable how data will span QCOW2 space?
On 7 Apr 2021, at 18:43, Nir Soffer <nsoffer(a)redhat.com>
wrote:
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