From owner-freebsd-arm@FreeBSD.ORG Sat May 31 13:20:28 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 7D388303; Sat, 31 May 2014 13:20:28 +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 2245C287E; Sat, 31 May 2014 13:20:27 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s4VDK7CZ017322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 31 May 2014 15:20:08 +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 s4VDK3fL061192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 15:20:03 +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 s4VDK3qZ051807; Sat, 31 May 2014 15:20:03 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s4VDK2P7051806; Sat, 31 May 2014 15:20:02 +0200 (CEST) (envelope-from ticso) Date: Sat, 31 May 2014 15:20:02 +0200 From: Bernd Walter To: Jia-Shiun Li Subject: Re: TRIM on SD cards Message-ID: <20140531132002.GL26883@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531044152.GK43976@funkthat.com> <20140531083849.GJ26883@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140531083849.GJ26883@cicely7.cicely.de> 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 , Ian Lepore , 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 13:20:28 -0000 On Sat, May 31, 2014 at 10:38:49AM +0200, Bernd Walter wrote: > On Sat, May 31, 2014 at 01:21:45PM +0800, Jia-Shiun Li wrote: > > On Sat, May 31, 2014 at 12:41 PM, John-Mark Gurney wrote: > > > Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600: > > >> Blocks of zeros can safely be BIO_DELETEd. Why, because nonexistent blocks are, by definition, all zeros. The only time there?s a problem is when the TRIM doesn?t really TRIM? You don?t need it to be sparse at all. Zeros are zeros. > > > > > > Are you sure? TRIM'd space may or may not have a defined value to > > > return upon read, and what happens if one of those blocks of zeros > > > belongs to a file that needs those zeros to be zero? > > > > > > There are bits that declare if the drive returns zeros or not, so this > > > would only be safe on those drives.. > > > > > > > For the original question, the need is to keep info about written > > blocks with the image it self, rather than directly issuing delete on > > media. I think it is easier to > > - erase all sdcard blocks before writing image, > > - teach md to write sparse file, and > > - teach dd to only write blocks according to info got from sparse image file. > > > > In current status block usage info got lost during image creation. > > Zeroes do not guarantee their existence can be safely ignored. On the > > other hand read from deleted block does not guarantee zeroes either. I > > know little about sdcard, but ATA defines a TRIMmed block as being one > > of the following behaviors on read, according to device: > > > > - non-deterministic read, each read *may* get different value > > - deterministic read value, reads can be *any* fixed value > > - deterministic read zero, reads are always zero. > > > > in practice at least both case 1 & 3 exist. > > Well Ok. > I thought TRIM'ed blocks return zero and it would be possible to > autodetect zero blocks in images. > Anyway, this is only one part of my first mail. > Sorry - my first mail wasn't very clear about this, but there are two > other parts. > > Is there any option to TRIM a filesystem at a later point? > Newfs can TRIM unused space of new filesystems and tunefs ensure > TRIM for freshly emptied blocks. > But what can I do when upgrading old systems? > With the above I need to copy the data and newfs. > > I don't have to use images at all, but I do have to handle USB > cardreader, unless I go another step further and setup a special > environment with raw MMC/SD controller to write cards. > How can I be sure that a given USB SD-reader really handles the TRIM? > In my case I didn't get an error, but does it mean the blocks are > really TRIM'ed? Ok - so much about "I got no error". In fact there was one, but this was a kernel message I didn't saw on my shell: WARNING: /mnt: TRIM flag on fs but disk does not support TRIM Interestingly newfs -E worked without errors. I've tried some USB sticks and readers, but all issued this error message. So it seems that either my USB reader or the card don't support TRIM. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.