Re: Making discard/fstrim reliable

[Jeff Moyer <jmoyer@redhat.com>]

"Richard W.M. Jones" <rjones@redhat.com> writes:

Hi, Richard,

> virt-sparsify is a tool for trimming free space in virtual disk
> images.  The new implementation uses vfs/kernel/qemu discard support.
> Essentially it does:
>

Presumably there's a "start guest" step here that's missing?

>   for each filesystem:
>     mount -o discard $fs /mnt

What is $fs?  Do you pass in a list of devices?

Also, you don't need to mount with -o discard in order to use fstrim.
In fact, I'd recommend against doing that.

>     sync

Interesting.  Have you seen mount dirty inodes or something?

>     fstrim /mnt
>     umount /mnt
>   sync
>   # qemu is killed after sync returns
>
> Although typing these commands by hand works fine, when you run them
> from a program the fstrim doesn't happen all the way down the stack
> reliably.  Mostly it works, but sometimes it only trims some space
> from the host file.

What is in the stack?  Are you using qcow2 images, plain files, device
mapper, anything else?  Which file systems are you testing, and are they
used in the host, the guest or both?  How are you checking for success?
Do you have a golden image you start with so that your test case is
repeatable?

> It appears that when the host is slow / under load, the problem
> happens more frequently.  Also it may happen more frequently on i686
> than on x86-64 (possibly also due to speed of host).

I don't know of any reason that any of the variables you listed would
affect the reliability at all.  As far as I can tell, fstrim is a
synchronous ioctl.  I believe the only reason space wouldn't be freed is
if the fs is fragmented in such a way as to not meet the minimum trim
granularity of the underlying device.  Of course, there may be file
system specific reasons too, I guess.  Hopefully others can comment on
that.

Cheers,
Jeff

> The question is: What can I do to make sure the trim happens reliably,
> all the way down the stack, before qemu is killed?
>
> I am testing this using the latest upstream kernel & qemu.
>
> Rich.