[Bug 47801] New: Growing build/wine VM disk usage

[WineHQ Bugzilla]

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 at winehq.org
          Reporter: fgouget at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.