TRIM on SD cards

[Warner Losh]

On May 31, 2014, at 7:20 AM, Bernd Walter <ticso at cicely7.cicely.de> wrote:

> On Sat, May 31, 2014 at 10:38:49AM +0200, Bernd Walter wrote:
>> On Sat, May 31, 2014 at 01:21:45PM +0800, Jia-Shiun Li wrote:
>>> On Sat, May 31, 2014 at 12:41 PM, John-Mark Gurney <jmg at funkthat.com> wrote:
>>>> Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600:
>>>>> 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..
>>>> 
>>> 
>>> For the original question, the need is to keep info about written
>>> blocks with the image it self, rather than directly issuing delete on
>>> media. I think it is easier to
>>> - erase all sdcard blocks before writing image,
>>> - teach md to write sparse file, and
>>> - teach dd to only write blocks according to info got from sparse image file.
>>> 
>>> In current status block usage info got lost during image creation.
>>> Zeroes do not guarantee their existence can be safely ignored. On the
>>> other hand read from deleted block does not guarantee zeroes either. I
>>> know little about sdcard, but ATA defines a TRIMmed block as being one
>>> of the following behaviors on read, according to device:
>>> 
>>> - non-deterministic read, each read *may* get different value
>>> - deterministic read value, reads can be *any* fixed value
>>> - deterministic read zero, reads are always zero.
>>> 
>>> in practice at least both case 1 & 3 exist.
>> 
>> Well Ok.
>> I thought TRIM'ed blocks return zero and it would be possible to
>> autodetect zero blocks in images.
>> Anyway, this is only one part of my first mail.
>> Sorry - my first mail wasn't very clear about this, but there are two
>> other parts.
>> 
>> Is there any option to TRIM a filesystem at a later point?
>> Newfs can TRIM unused space of new filesystems and tunefs ensure
>> TRIM for freshly emptied blocks.
>> But what can I do when upgrading old systems?
>> With the above I need to copy the data and newfs.
>> 
>> I don't have to use images at all, but I do have to handle USB
>> cardreader, unless I go another step further and setup a special
>> environment with raw MMC/SD controller to write cards.
>> How can I be sure that a given USB SD-reader really handles the TRIM?
>> In my case I didn't get an error, but does it mean the blocks are
>> really TRIM'ed?
> 
> Ok - so much about "I got no error".
> In fact there was one, but this was a kernel message I didn't saw
> on my shell:
> WARNING: /mnt: TRIM flag on fs but disk does not support TRIM
> Interestingly newfs -E worked without errors.
> I've tried some USB sticks and readers, but all issued this error
> message.
> So it seems that either my USB reader or the card don't support TRIM.

That’s why I think we’ll need to trim on the actual target. It could also be that umass doesn’t support BIO_DELETE properly by not translating that info to indicate TRIM or UNMAP or WS is supported. It would take some quality time with the da driver to find out for sure, plus looking at the USB specs. CMD38 is listed as mandatory, except for ROM cards.

First, the SD card standard guarantees a value, which is good. The bad news is that the value guaranteed varies from card to card. CMD38 is used to erase the data. The standard says:

The data at the card after an erase operation is either '0' or '1', depends on the card vendor. 
The SCR register bit DATA_STAT_AFTER_ERASE (bit 55) defines whether it is '0' or '1'. 
 
which is less useful than I’d hoped. This implies either that we hope for it to be 0, then write a trivial program to read blocks and trim the zero’d ones, or we have to know the extents that are valid or invalid, which is much harder….

This suggests looking at umass and/or the SD adapter card would be fruitful…

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/20140531/3ee792bf/attachment.sig>