From owner-freebsd-arm@FreeBSD.ORG Sat May 31 10:23:33 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7605DC95; Sat, 31 May 2014 10:23:33 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DB8882BC3; Sat, 31 May 2014 10:23:32 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s4VANED2015992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 31 May 2014 12:23:14 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s4VAN5Fk060017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 12:23:06 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s4VAN5b9050869; Sat, 31 May 2014 12:23:05 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s4VAN5h8050868; Sat, 31 May 2014 12:23:05 +0200 (CEST) (envelope-from ticso) Date: Sat, 31 May 2014 12:23:05 +0200 From: Bernd Walter To: Ian Lepore Subject: Re: TRIM on SD cards Message-ID: <20140531102305.GK26883@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1401505209.20883.34.camel@revolution.hippie.lan> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@FreeBSD.org, Bernd Walter , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 10:23:33 -0000 On Fri, May 30, 2014 at 09:00:09PM -0600, Ian Lepore wrote: > On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote: > > It seems SD cards support a delete command, which FreeBSD supports > > with the mmcsd driver. > > newfs and tunefs support TRIM in that new filesystems are trim'ed > > and the filesystems automatically trim free'ed blocks. > > So far so good. > > On the practical side with SD based ARM you don't write filesystems > > directly via mmcsd. > > We either create an image, which id dd'ed onto SD or in some cases > > we use an USB SD drive. > > With dd the unused blocks are written as well, which effectively > > hurts by writing data. > > Is there some kind of dd, which actually don't write zero blocks, > > or even better does a trim call for them? > > I don't think dd can safely do that. If it finds a block of zeroes on > the input side, how does it know it's okay to do a DELETE for those > (which sets the block to all-bits-on on most flash media). Maybe it's > important for that data to really be zero; dd doesn't know. That 1 bit thing is true for raw flash media. A amanged NAND flash device simply unmaps a logical block from physical storage. This is similar to having holes in an ufs file, which per definition returns zero when reading a hole range. However from reading the thread it is not save to assume managed flash devices return zero blocks when reading TRIM'ed space. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.