From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiXLu-0007M8-Us for qemu-devel@nongnu.org; Sat, 23 Jun 2012 16:54:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SiXLt-0007pz-9f for qemu-devel@nongnu.org; Sat, 23 Jun 2012 16:54:42 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:60072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiXLt-0007pm-10 for qemu-devel@nongnu.org; Sat, 23 Jun 2012 16:54:41 -0400 Received: by pbbro12 with SMTP id ro12so5123299pbb.4 for ; Sat, 23 Jun 2012 13:54:37 -0700 (PDT) Sender: fluxion Date: Sat, 23 Jun 2012 15:54:30 -0500 From: Michael Roth Message-ID: <20120623205430.GA7553@illuin> References: <1340319857-28198-1-git-send-email-mdroth@linux.vnet.ibm.com> <1340319857-28198-3-git-send-email-mdroth@linux.vnet.ibm.com> <20120622174856.GA6505@puku.stupidest.org> <20120622211224.GA3020@illuin> <20120623033851.GA10913@puku.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120623033851.GA10913@puku.stupidest.org> Subject: Re: [Qemu-devel] [PATCH 2/2] qemu-ga: add guest-fstrim command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chris Wedgwood Cc: pbonzini@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org On Fri, Jun 22, 2012 at 08:38:51PM -0700, Chris Wedgwood wrote: > > I'm not sure I understand, wouldn't the filesystem need to be involved > > at some level? How can the block layer differentiate lazilly discarded data > > blocks from ones that are still in use without the aid of the > > filesystem? > > It might be me that doesn't understand. > > Yes, the filesystem is involved. Current linux filesystems can trim > on demand or using fstrim. That mechanism seems to be like it should > suffice if exposed in the most common cases. > You mean the "discard" mount option? I don't think that's generally enabled by default due to the performance impact on bare metal. A periodic, filesystem-wide call (like the FITRIM ioctl) is probably the better approach in those cases as well. I'm not sure what the penalty of auto-discard would be in the case of VMs, but there would be at least some additional overhead there due the hole punching operations run by the host, and the only use case I can think of where it's useful in that context is for reducing the size of the images before we do some work with them on the host, in which case an explicit FITRIM ioctl beforehand makes the most sense IMO.