From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IHm13-0002Ld-Hl for qemu-devel@nongnu.org; Sun, 05 Aug 2007 15:43:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IHm0z-0002JW-SJ for qemu-devel@nongnu.org; Sun, 05 Aug 2007 15:43:53 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IHm0z-0002JJ-Fd for qemu-devel@nongnu.org; Sun, 05 Aug 2007 15:43:49 -0400 Received: from mout.perfora.net ([74.208.4.194]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IHm0x-0001mT-IL for qemu-devel@nongnu.org; Sun, 05 Aug 2007 15:43:48 -0400 Message-ID: <46B628B1.3070602@filteredperception.org> Date: Sun, 05 Aug 2007 14:44:49 -0500 From: dmc MIME-Version: 1.0 Subject: Re: [Qemu-devel] RFE- snapshot data storage location configurable References: <46AFE651.8080306@filteredperception.org> <46B5B20C.9040107@artenumerica.com> In-Reply-To: <46B5B20C.9040107@artenumerica.com> Content-Type: multipart/mixed; boundary="------------040203070307040203070009" Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------040203070307040203070009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------040203070307040203070009 Content-Type: text/x-patch; name="qemu-0.8.1-cowtmpdirenv.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="qemu-0.8.1-cowtmpdirenv.patch" 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); } --------------040203070307040203070009--