From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: Making discard/fstrim reliable Date: Thu, 03 Apr 2014 19:57:59 +0200 Message-ID: <533DA127.5090909@redhat.com> References: <20140326204708.GA29191@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org To: =?UTF-8?B?THVrw6HFoSBDemVybmVy?= , "Richard W.M. Jones" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:6399 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752918AbaDCR6C (ORCPT ); Thu, 3 Apr 2014 13:58:02 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s33Hw2lN016862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 3 Apr 2014 13:58:02 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Il 03/04/2014 19:08, Luk=C3=A1=C5=A1 Czerner ha scritto: > However if we're talking about raw file system images in files in > the host, then much better solution would be to use fsck. Ext4 > already has option -E discard which will send a discard down for > ever free range (similarly as fstrim would do on mounted file > system). I suspect that other fs utilities might have similar > functionality. > > Of course in order for it to work you need a layer to translate > discard requests to punch holes to the underlying file system (such > as loop device for example). But I think that if there is enough > interest we might do this directly from e2fsck when we notice that > we're running on the file rather than block device. The e2fsck can also be done from within libguestfs easily. libguestfs=20 runs within a VM so QEMU would handle the translation to hole-punching. But fstrim is much faster than e2fsck. From Richard's description, what seems to happen is that ext4 FITRIM=20 scans the filesystem and prepares the discard requests; but then it=20 sends them down to the filesystem after the ioctl has finished. Does=20 that make any sense? And would that be considered a bug? Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html