"Richard W.M. Jones" <rjones@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
