TRIM on SD cards

[Warner Losh]

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.

Warner


> -- Ian
> 
>> Is there a tool to trim a filesystem after creation?
>> Ok - even then there is the option to directly newfs on the SD card.
>> But in any case I need to be able to issue trim requests to the card.
>> It seems there is support in our da driver, but will it be transported
>> to the USB reader and even if - how can I find out if my reader actually
>> supports trim commands?
>> A newfs -t -E with my older transcend multireader and a new class10
>> Intenso micro-SD issues no error.
>> But is it save to assume the card actually got trim'ed?
>> 
>> Trim is enabled on the filesystem, but not shown in mount list:
>> [189]gw1# tunefs -t enable /dev/da0
>> tunefs: issue TRIM to the disk remains unchanged as enabled
>> [190]gw1# mount /dev/da0 /mnt
>> [191]gw1# mount | grep mnt
>> /dev/da0 on /mnt (ufs, local, soft-updates)
>> FreeBSD gw1.cicely.de 10.0-STABLE FreeBSD 10.0-STABLE #0: Thu Apr 17 11:47:45 CEST 2014     ticso at gw1.cicely.de:/usr/obj/home/builder/gw1/10/sys/GW1  i386
>> 
> 
> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

-------------- 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/05b8194c/attachment.sig>