From: dmc <dmc@filteredperception.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] RFE- snapshot data storage location configurable
Date: Sun, 05 Aug 2007 14:44:49 -0500 [thread overview]
Message-ID: <46B628B1.3070602@filteredperception.org> (raw)
In-Reply-To: <46B5B20C.9040107@artenumerica.com>
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]
J M Cerqueira Esteves wrote:
> dmc wrote:
>> I have a pretty ugly patch against qemu 0.8 which allows the location of
>> data used with the -snapshot feature to be somewhere other than
>> /var/tmp. I have a use-case where I am creating many gigabytes of
>> changes to disk in snapshot mode. When 0.9 came out, I looked, but it
>> seemed less than trivial to update my patch, which was a pretty ugly
>> hack to begin with.
>>
>> I don't suppose anybody else thinks this would be a useful feature?
>
> It would certainly be useful, as I found out yesterday :) while testing
> installation of a big software package in a Windows virtual machine in
> snapshot mode (with 0.9.0) even though the (Linux) host's /tmp had about
> 1 GB.
>
> I would suggest at least honoring the TMPDIR environment variable (which
> is not being taken into account).
Yeah, my 0.8.1 solution was QEMU_COW_TMPDIR, since I was too lazy to do
something like tracking down all the places in the code that a more general
TMPDIR should probably be respected.
For what it's worth, attached is my trivial 0.8.1 patch. I may take a second
look at updating it, but it's not a high priority for me at the moment.
-dmc
[-- Attachment #2: qemu-0.8.1-cowtmpdirenv.patch --]
[-- Type: text/x-patch, Size: 857 bytes --]
diff -Naur qemu-0.8.1.orig/block.c qemu-0.8.1.cowtmpdirenv/block.c
--- qemu-0.8.1.orig/block.c 2006-06-22 02:14:55.000000000 +0000
+++ qemu-0.8.1.cowtmpdirenv/block.c 2006-06-22 02:23:03.000000000 +0000
@@ -169,8 +169,19 @@
void get_tmp_filename(char *filename, int size)
{
int fd;
+ const char *tmpdir;
+
+ tmpdir = getenv("QEMU_COW_TMPDIR");
+ if (!tmpdir)
+ tmpdir = "/tmp";
+ snprintf(filename, size, "%s/vl.XXXXXX", tmpdir);
+
/* XXX: race condition possible */
- pstrcpy(filename, size, "/tmp/vl.XXXXXX");
+ /* COWTMPDIR: I don't understand the possible race condition in the
+ below line of code, so I have no idea if it still applies to
+ the above alternate method for creating filename */
+ /* pstrcpy(filename, size, "/tmp/vl.XXXXXX"); */
+
fd = mkstemp(filename);
close(fd);
}
next prev parent reply other threads:[~2007-08-05 19:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-01 1:48 [Qemu-devel] RFE- snapshot data storage location configurable dmc
2007-08-05 11:18 ` J M Cerqueira Esteves
2007-08-05 19:44 ` dmc [this message]
2007-08-11 16:16 ` andrzej zaborowski
2007-08-11 18:41 ` dmc
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=46B628B1.3070602@filteredperception.org \
--to=dmc@filteredperception.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.