From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43649) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S71eA-0008Is-Nz for qemu-devel@nongnu.org; Mon, 12 Mar 2012 05:34:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S71dl-0006nW-Se for qemu-devel@nongnu.org; Mon, 12 Mar 2012 05:34:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64525) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S71dl-0006lA-Kh for qemu-devel@nongnu.org; Mon, 12 Mar 2012 05:34:05 -0400 Message-ID: <4F5DC309.7050709@redhat.com> Date: Mon, 12 Mar 2012 10:34:01 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1331226917-6658-1-git-send-email-pbonzini@redhat.com> <1331226917-6658-15-git-send-email-pbonzini@redhat.com> <1331325410.3715.77.camel@watermelon.coderich.net> In-Reply-To: <1331325410.3715.77.camel@watermelon.coderich.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 14/17] block: support FALLOC_FL_PUNCH_HOLE trimming List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Laager Cc: qemu-devel@nongnu.org Il 09/03/2012 21:36, Richard Laager ha scritto: > fallocate() only supports files. In my patch, I was fstat()ing the fd > just after opening it and caching an is_device boolean. Then, when doing > discards, if !is_device, call fallocate(), else (i.e. for devices) do > the following (note: untested code): > > __uint64_t range[2]; > > range[0] = sector_num << 9; > range[1] = (__uint64_t)nb_sectors << 9; > > if (ioctl(s->fd, BLKDISCARD, &range) && errno != EOPNOTSUPP) { > return -errno; > } > return 0; You can instead put this code in a separate function hdev_discard. hdev device is used instead of file when the backend is a special file (block or character). > -------- sync requirements -------- > > I'm not sure if fallocate() and/or BLKDISCARD always guarantee that the > discard has made it to stable storage. If they don't, does O_DIRECT or > O_DSYNC on open() cause them to make any such guarantee? O_DIRECT shouldn't have any effect; for O_DSYNC I don't think so. > -------- Thin vs. Thick Provisioning -------- > > On Fri, 2012-03-09 at 00:35 -0800, Chris Wedgwood wrote: >> Simplest still compare the blocks allocated by the file >> to it's length (ie. stat.st_blocks != stat.st_size>>9). > > I thought of this as well. It covers "99%" of the cases, but there's one > case where it breaks down. Imagine I have a sparse file backing my > virtual disk. In the guest, I fill the virtual disk 100%. Then, I > restart QEMU. Now it thinks that sparse file is non-sparse and stops > issuing hole punches. I would not really have any problem with that, it seems like a relatively minor case (also because newer guests will allocate the first partition at 1 MB, so you might still have a small hole at the beginning). > To be completely correct, I suggest the following behavior: > 1. Add a discard boolean option to the disk layer. > 2. If discard is not specified: > * For files, detect a true/false value by comparing > stat.st_blocks != stat.st_size>>9. > * For devices, assume a fixed value (true?). > 3. If discard is true, issue discards. > 4. If discard is false, do not issue discards. The problem is, who will use this interface? Paolo