Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 May 2014 21:41:53 -0700
From:      John-Mark Gurney <jmg@funkthat.com>
To:        Warner Losh <imp@bsdimp.com>
Cc:        freebsd-arm@freebsd.org, Bernd Walter <ticso@cicely7.cicely.de>, ticso@cicely.de, Ian Lepore <ian@freebsd.org>
Subject:   Re: TRIM on SD cards
Message-ID:  <20140531044152.GK43976@funkthat.com>
In-Reply-To: <CC7D4DF1-7CE3-445C-9EB2-9CB0856E0AFA@bsdimp.com>
References:  <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <CC7D4DF1-7CE3-445C-9EB2-9CB0856E0AFA@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600:
> On May 30, 2014, at 9:00 PM, Ian Lepore <ian@FreeBSD.org> 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's one of the reasons why I recently mentioned a desire for
> > a /dev/ones to go with /dev/zero as a way of pre-init'ing an image to be
> > more friendly to flash media.  The idea was not well-received by other
> > freebsd folks.
> > 
> > Maybe if the image was sparse, dd could tell the difference between an
> > missing segment and a segment populated with zeroes and do a DELETE for
> > missing data.  I never do the image creation thing, I mostly tend to use
> > nfsroot and at $work we use tar to copy files to sdcards with a usb
> > burner rather than preformatting images into files.
> 
> 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..

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140531044152.GK43976>