From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH] [RFC] qemu-upstream: add discard support for xen_disk Date: Fri, 17 Jan 2014 17:06:53 +0100 Message-ID: <20140117160653.GA20783@aepfle.de> References: <1389304875-4311-1-git-send-email-olaf@aepfle.de> <20140117152930.GA13324@aepfle.de> <20140117153820.GA17569@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Fri, Jan 17, Stefano Stabellini wrote: > Can't we just assume that if the backend can do discard on that file, it > is simply going to enable feature-discard? Do we really need the > toolstack driven option too? If the backing file is fully ppopulated on purpose to avoid fragmentation of that file, then silently enabling discard means the unwanted fragmentation will occour over time. If anyone is really doing that in their setup I certainly dont know. At least kvm/qemu has such knob, and also an hyperv host offers sparse, fully populated and overlay as possible option when creating a new virtual disk image. Now I think that if libxl already writes feature-discard=0, qemu can use that to clear BDRV_O_UNMAP. Also blkbk could be extended to first check if the property already exists before blindly enabling discard. No idea if that makes sense for "phy", but you never know. Olaf