From owner-freebsd-arm@FreeBSD.ORG Sat May 31 17:48:24 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D3DF83F for ; Sat, 31 May 2014 17:48:24 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5EB142D1F for ; Sat, 31 May 2014 17:48:24 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WqnOI-000FHG-Gm; Sat, 31 May 2014 17:48:22 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4VHmJ7q001346; Sat, 31 May 2014 11:48:19 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Cks9CFBxbbyJNsqv/POtK Subject: Re: TRIM on SD cards From: Ian Lepore To: Warner Losh In-Reply-To: <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> Content-Type: text/plain; charset="windows-1251" Date: Sat, 31 May 2014 11:48:19 -0600 Message-ID: <1401558499.20883.44.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s4VHmJ7q001346 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 17:48:24 -0000 On Sat, 2014-05-31 at 10:45 -0600, Warner Losh wrote: > On May 31, 2014, at 4:23 AM, Bernd Walter wro= te: >=20 > > 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? > >>=20 > >> 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. > >=20 > > That 1 bit thing is true for raw flash media. > > A amanged NAND flash device simply unmaps a logical block from physic= al > > 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 flas= h > > devices return zero blocks when reading TRIM'ed space. >=20 > One of the things that I did for images years ago was compressed tar fi= les. There was so much variation between CF makers and at the time CF geo= metry was important to the BIOS, so we made our images as tar balls. We t= hen had a makefile target that would create a partition on the card that = was actually there, put boot blocks on it then extract the tarball=85 I = never have liked DD for creating images, even when LBAs ruled the day bec= ause you=92d always have to grow/shrink the FS afterwards. The only advan= tage it had was it was easy=85 Perhaps it is time to go back to that mode= l? The alternative that wouldn=92t suck too bad would be to create variab= le sized images based on how much data was actually present and ensure th= ere are no holes (or minimal holes) in the filesystem. >=20 > Hmmm, if we know WHAT filesystem we=92re dealing with, then we could pe= rhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that it kno= ws are free, which would be a useful, data-driven approach that could ens= ure we start out with a nicely trimmed FS. Given the vagaries of the diff= erent kinds of TRIMs and the various translation layers we have, that mig= ht be the most robust. >=20 > Warner >=20 I wouldn't at all mind an fsck or growfs option or a standalone tool that would issue deletes for unused blocks on an existing filesystem. I have several big SSDs on this system and I had no TRIM support for a long time, so there are lots of blocks on the drives that bogusly look used to the onboard block management code. -- Ian