qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] TRIM/DISCARD/UNMAP support on qemu-nbd


From: Paolo Bonzini
Subject: Re: [Qemu-devel] TRIM/DISCARD/UNMAP support on qemu-nbd
Date: Wed, 08 Jan 2014 23:45:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]