From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fg3EV-0007eI-UE for qemu-devel@nongnu.org; Tue, 16 May 2006 13:21:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fg3EV-0007ds-Aj for qemu-devel@nongnu.org; Tue, 16 May 2006 13:21:19 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fg3EV-0007dn-70 for qemu-devel@nongnu.org; Tue, 16 May 2006 13:21:19 -0400 Received: from [128.8.10.163] (helo=po1.wam.umd.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fg3HB-0000ef-9z for qemu-devel@nongnu.org; Tue, 16 May 2006 13:24:05 -0400 Received: from jbrown.mylinuxbox.org (jma-box.student.umd.edu [129.2.253.219]) by po1.wam.umd.edu (8.12.11.20060308/8.12.10) with ESMTP id k4GHLH1d024872 for ; Tue, 16 May 2006 13:21:17 -0400 (EDT) Date: Tue, 16 May 2006 13:21:16 -0400 From: "Jim C. Brown" Subject: Re: [Qemu-devel] Re: qemu disk on vfat Message-ID: <20060516172116.GA15611@jbrown.mylinuxbox.org> References: <1147218062.9211.2.camel@localhost> <20060508224846.GA9668@jbrown.mylinuxbox.org> <20060508231032.GA12871@jbrown.mylinuxbox.org> <20060508235024.GA18407@jbrown.mylinuxbox.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <20060508235024.GA18407@jbrown.mylinuxbox.org> 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 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, May 08, 2006 at 08:36:15PM -0500, Anthony Liguori wrote: > Jim C. Brown wrote: > >Aactually, the bug is in vfat not in qemu-img. > > > > Not really. POSIX doesn't mandate that ftruncate() increase a file > size. This is a Linux-ism and is only valid for filesystems that > support holes (which vfat doesn't). > > Regards, > > Anthony Liguori > Ok, so in that case this is something qemu-img should handle on its own then. (Since we're not likely to see a "fix" in either glibc or the kernel for this, and it has the potential to be a portability issue.) On Mon, May 08, 2006 at 07:50:24PM -0400, Jim C. Brown wrote: > qemu-img correctly uses ftruncate() which is suppose to make the file sparse > if the underlying filesystem supports it, but it should fall back to adding zeros > to the end of the file. On vfat you aren't able to seek past the end of a file > period, so this doesn't work. Turns out I was wrong about this too. http://www.mail-archive.com/bug-tar@gnu.org/msg00556.html Here is a patch that silently handles the Linux/vfat case using lseek(). -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="block.patch" --- block.c Tue May 16 13:06:15 2006 +++ block.c Tue May 16 13:07:51 2006 @@ -753,6 +753,20 @@ close(s->fd); } +int qemu_ftruncate(int fd, off_t length) +/* ftruncate() isn't guarranteed to grow a file, according to POSIX. ** +** This is. */ +{ + int res = ftruncate(fd, length); + if (res && (errno == EPERM)) + { + if ((lseek( fd, length - 1, SEEK_SET) == (off_t)-1) || + (write(fd, "\0", 1) == -1)) + return -1; + } + return res; +} + static int raw_create(const char *filename, int64_t total_size, const char *backing_file, int flags) { @@ -765,7 +779,7 @@ 0644); if (fd < 0) return -EIO; - ftruncate(fd, total_size * 512); + qemu_ftruncate(fd, total_size * 512); close(fd); return 0; } --CE+1k2dSO48ffgeK--