TRIM on SD cards

[Bernd Walter]

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.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.