Date: Sat, 31 May 2014 12:23:32 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Jim Thompson <jim@netgate.com> Cc: Ian Lepore <ian@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Bernd Walter <ticso@cicely7.cicely.de>, "ticso@cicely.de" <ticso@cicely.de> Subject: Re: TRIM on SD cards Message-ID: <20140531192332.GM43976@funkthat.com> In-Reply-To: <54DF962E-4A84-4309-ABCE-DB2DA12DAE0A@netgate.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> <54DF962E-4A84-4309-ABCE-DB2DA12DAE0A@netgate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jim Thompson wrote this message on Sat, May 31, 2014 at 00:37 -0500:
> > On May 30, 2014, at 11: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?
> >
> > There are bits that declare if the drive returns zeros or not, so this
> > would only be safe on those drives..
>
> Since time immortal (23:59:59 31 Dec 1969), or at least 1978 or so, the file system has supported the idea of sparse files.
Yep, easier:
$ truncate -s 2048t /tmp/largefile
$ ls -sl /tmp/largefile
128 -rw-r--r-- 1 jmg wheel 2251799813685248 May 31 12:19 /tmp/largefile
[...]
> Unix doesn't zero the blocks on the free list. This is the same. TRIM just tells the drive that the block is free. The file system already knows.
>
> The above will fail if foo exists and is at least 1MB in size. Sorry.
We are talking about two different thing... I'm talking about what the
drive does, and you, what the FS does.. There are no guarantees that
zero blocks in an FS will not be pointed to by a file... I just realized
that parts of the FS metadata such as the block usage bitmap could be
zero, and there for trimmed by autodetecting zeros...
But doesn't most flash adaption layers auto detect blocks of zeros, and
not write them anyways? and instead write a market note that this is all
zeros? If that is true, than detecting blocks of zero and trimming o
that just makes the software more complicated...
--
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?20140531192332.GM43976>