TRIM on SD cards

[Jim Thompson]

> On May 30, 2014, at 11: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?
> 
> 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.   

From the iPad, so no error checking or indentation...

#include <stdio.h>
#include <sys/stat.h>

main()
{

int fd;
struct stat st = {0};

fd = open("foo", 2);
lseek(fd, 1024*1024, SEEK_SET);
write(fd, '\0', 1);
fstat(fd,&st);

if (st.st_blocksize * st.st_blocks < st.st_size)
      printf("file is sparse\n);

close(fd);
exit(0);
}

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. 

Jim