Date: Sat, 31 May 2014 02:08:48 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm <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: <20140531090847.GL43976@funkthat.com> In-Reply-To: <54E44307-F5AF-4ED5-9566-18C5A3AF86DD@bsdimp.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <CC7D4DF1-7CE3-445C-9EB2-9CB0856E0AFA@bsdimp.com> <20140531044152.GK43976@funkthat.com> <54E44307-F5AF-4ED5-9566-18C5A3AF86DD@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 23:06 -0600:
> On May 30, 2014, at 10:41 PM, John-Mark Gurney <jmg@funkthat.com> wrote:
>
> > 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?
>
> TRIM unmaps the block. Unmapped blocks are required by the standard to return 0?s. But the problem is there whether the images are written out sparse or not: blocks of zeros are the same as blocks of missing data (which return zeros).
We only check that the drive supports _DSM_TRIM... We would also
need to check that ATA_SUPPORT_RZAT and ATA_SUPPORT_DRAT are set in
support3, but I don't see us doing that... This is per 7.9.3.2 of the
ACS-3 ATA spec...
if ((cgd.ident_data.support_dsm & ATA_SUPPORT_DSM_TRIM) &&
(cgd.inq_flags & SID_DMA))
softc->flags |= ADA_FLAG_CAN_TRIM;
else
softc->flags &= ~ADA_FLAG_CAN_TRIM;
> > There are bits that declare if the drive returns zeros or not, so this
> > would only be safe on those drives..
>
> On the drives where they don?t, we don?t do TRIM, if I?m reading the code correctly? But it would be worth a check. Let me check the SD card standard?
I haven't checked the SD card standard, I was only looking at the ATA
standard...
--
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?20140531090847.GL43976>