From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzmRq-0005vi-Ly for qemu-devel@nongnu.org; Fri, 10 Aug 2012 06:28:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SzmRp-0006sH-Kt for qemu-devel@nongnu.org; Fri, 10 Aug 2012 06:28:06 -0400 Received: from mail.profihost.ag ([85.158.179.208]:54967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzmRp-0006rr-BD for qemu-devel@nongnu.org; Fri, 10 Aug 2012 06:28:05 -0400 Message-ID: <5024E232.5020706@profihost.ag> Date: Fri, 10 Aug 2012 12:28:02 +0200 From: Stefan Priebe - Profihost AG MIME-Version: 1.0 References: <502283FA.2080506@profihost.ag> <5022912B.2000607@redhat.com> <50235527.4090804@profihost.ag> <50236059.7060801@redhat.com> <4A799203-5BFF-4DE9-9B85-459096EBEC22@profihost.ag> <50236484.2090702@redhat.com> <502369C7.7000300@profihost.ag> <50238E2A.1050203@profihost.ag> <5024D2E7.40700@profihost.ag> <5024E06A.4070603@redhat.com> In-Reply-To: <5024E06A.4070603@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] virtio-scsi vs. virtio-blk List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Stefan Hajnoczi , qemu-devel I'm using iscsi. So no raw or qcow2. XFS as FS. Thanks, Stefan Am 10.08.2012 12:20, schrieb Paolo Bonzini: > Il 10/08/2012 11:22, Stefan Priebe - Profihost AG ha scritto: >> virtio-scsi is now working fine. Could you please help me to get discard >> / trim running? I can't find any information what is needed to get >> discard / trim working. > > You need to add discard_granularity=NNN, where NNN is usually 512 for > raw and the cluster size (65536) for qcow2. > > However, discard is supported only for XFS on raw, and on qcow2 it will > not reclaim space---the space will only be reused for future qcow2 > allocation. > > Better support for discard on raw (other filesystems + block devices), > and more efficient support also on other formats is on my todo list for > the future. However, an efficient implementation unfortunately requires > changes at all levels including the kernel. > > I hope to present something about it at KVM Forum. > > Paolo >