From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Fam Zheng <famz@redhat.com>, QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] vm-tests images disks filling up?
Date: Fri, 17 Aug 2018 12:00:18 +0100 [thread overview]
Message-ID: <20180817110018.GI11124@redhat.com> (raw)
In-Reply-To: <20180817104706.GH11124@redhat.com>
On Fri, Aug 17, 2018 at 11:47:06AM +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 17, 2018 at 11:26:39AM +0100, Peter Maydell wrote:
> > I just ran into a build failure using the tests/vm/ BSD build tests,
> > because the NetBSD build image's disk filled up.
> >
> > Looking more closely there seemed to be 9 stale build trees in
> > the VM's /var/tmp/qemu-test.* , which is why the disk was full
> > (they'd used up about 18GB between them).
> >
> > The other VMs (freebsd, openbsd) also had the same problem of
> > /var/tmp gradually filling with stale trees, they just hadn't
> > quite run out of space yet...
> >
> > What's the process for managing the disk space on these images?
> > How are stale or completed build trees deleted ?
>
> I'd prefer to see the test process honouring the build directory instead
> of putting stuff in /var/tmp, so that a developer's normal approach to
> cleaning up build artifacts works.
Oh, wait I'm stupid, you're talking about the /var/tmp inside the guest
disk images, not the host !
IIUC, the problem is that we create the tests/vm/freebsd.img file
by deep copying the template cached under $HOME and never purge it,
so it gradually fills up.
It would be desirable to guarantee a clean image for every build test
to avoid risk of previous problems affecting subsequent builds.
So how about we create tests/vm/freebsd.img as a qcow2 overlay that
points back to the cached image in $HOME. That makes it cheap to create,
so on every test we can just throw away the previous overlay to get
pristine state.
NB, don't delete the overlay at end of build - only start of the next
build. That gives devs a way to launch the VM to debug a failed build
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2018-08-17 11:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-17 10:26 [Qemu-devel] vm-tests images disks filling up? Peter Maydell
2018-08-17 10:47 ` Daniel P. Berrangé
2018-08-17 10:54 ` Peter Maydell
2018-08-17 11:00 ` Daniel P. Berrangé [this message]
2018-08-17 11:52 ` Fam Zheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180817110018.GI11124@redhat.com \
--to=berrange@redhat.com \
--cc=famz@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.