TRIM on SD cards

Bernd Walter ticso at cicely7.cicely.de
Sat May 31 08:39:13 UTC 2014


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?

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


More information about the freebsd-arm mailing list