From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W11so-0003BY-NN for qemu-devel@nongnu.org; Wed, 08 Jan 2014 17:46:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W11sg-0001ZT-4B for qemu-devel@nongnu.org; Wed, 08 Jan 2014 17:45:54 -0500 Received: from mail-ee0-x22b.google.com ([2a00:1450:4013:c00::22b]:36630) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W11sf-0001ZG-T6 for qemu-devel@nongnu.org; Wed, 08 Jan 2014 17:45:46 -0500 Received: by mail-ee0-f43.google.com with SMTP id c13so946071eek.2 for ; Wed, 08 Jan 2014 14:45:44 -0800 (PST) Sender: Paolo Bonzini Message-ID: <52CDD513.80408@redhat.com> Date: Wed, 08 Jan 2014 23:45:39 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20140102161503.GA14565@redhat.com> <52CC13D6.6000607@redhat.com> <20140107202708.GB1273@redhat.com> <52CC6811.4000107@redhat.com> <20140107212210.GB4802@redhat.com> <52CDCD17.8070508@redhat.com> <20140108222435.GO4802@redhat.com> In-Reply-To: <20140108222435.GO4802@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] TRIM/DISCARD/UNMAP support on qemu-nbd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: Teng-Feng Yang , qemu-devel@nongnu.org Il 08/01/2014 23:24, Richard W.M. Jones ha scritto: > On Wed, Jan 08, 2014 at 11:11:35PM +0100, Paolo Bonzini wrote: >> Is guestfish using "discard=on"? > > No. > > Adding the discard=on parameter does indeed fix this: > > 13M /tmp/test1 > 17M /tmp/test2 > > However why isn't this the default? Is there a case where discard=on > would be undesirable? It is always safe if supported. However, it may cause performance problems, because discarding data from images may make them fragmented, or cause files to have a lot of extents. Similarly for block devices backed by some kind of thin-provisioning NAS (instead it should always be okay for SSDs). Unfortunately neither Linux nor the block devices really provide the information you need to know whether discard can cause these problems. > It's extremely difficult to know when it's safe to add this parameter. > Qemu gives no indication of when using discard=.. is safe (ie. won't > cause qemu to fail to start up or fail in some other way). It's even > worse when we have to go via libvirt which itself doesn't expose > qemu's capabilities upwards. It is a bug that "-help" doesn't list discard=on, but QMP query-command-line-options lists it correctly. libvirt could safely ignore discard if the underlying QEMU does not support it, but that's not how it was implemented. Currently, explicitly specifying either discard='on' and discard='off' will cause the VM to fail to start if QEMU does not support it. There are tradeoffs in both solutions... Paolo