https://bugs.winehq.org/show_bug.cgi?id=47801
Bug ID: 47801 Summary: Growing build/wine VM disk usage Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com Distribution: ---
Created attachment 65291 --> https://bugs.winehq.org/attachment.cgi?id=65291 Evolution of wtbdebian10's revert times
Every time we update and rebuild Wine in these VMs the VM's qcow2 file grows. The Wine VMs are those where the disk grows fastest, from ~5 GB to 60+ GB in a matter of weeks. Fortunately it does seem to grow slower after a while.
For instance <6 GB to 32 GB (du) from 2019-09-20 to 2019-09-25 for wtbdebian10.
This may be caused by the way WineRunReconfig handles live snapshots. To summarize: * Restore to the current live snapshot. * Update and rebuild Wine. * Iff that succeeded, delete the live snapshot and recreate it.
This may cause QEmu to not realize that all the data from the now deleted old live snapshot can be reclaimed and reused for the next Wine build. But we had to delete the live snapshot at the last minute because losing it would mean the VM would be unusable until the TestBot administrator could come and fix it.
However nowadays the TestBot can recreate live snapshots from powered off snapshots. This means we could delete the live snapshot first, rebuild and recreate the snapshot at the end. In the unlikely event that something goes wrong the live snapshot could be recreated from the powered off 'base'... except in the case of a build error. That case would be unrecoverable unlike in the current scheme.
A test with this alternative snapshot management should be made to see if it does actually make a difference in the qcow2 growth (there's really no guarantee it does).
For these VMs the revert time does seem to degrade a bit with time(*). This may be related to the qcow2 size and/or accumulation of "phantom snapshots". So the experiment should be run for a while to see if it makes a difference on this metric too.
(*) See the Munin graph of wtbdebian10's revert time. The drop in week 38 and 39 correspond to maintenance on the VM where all snapshots were deleted and virt-sparsify run on its disk.