TRIM on SD cards

[Warner Losh]

On May 30, 2014, at 10:41 PM, John-Mark Gurney <jmg at 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 at 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).

> 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…

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140530/3e29fc38/attachment.sig>