| |||||||||||||
TRIM?TRIM?Posted Dec 12, 2012 1:22 UTC (Wed) by neilbrown (subscriber, #359)In reply to: TRIM? by cibyr Parent article: JFFS2, UBIFS, and the growth of flash storage
When you read from a region that was TRIMed the result is either undefined or all-zeros, whereas when you read from a region that was mtd_erase()d, the result is all-ones.
So it wouldn't really be useful to make mtd_erase() to TRIM. They do seem similar but they have quite different semantics.
(Log in to post comments)
TRIM? Posted Dec 12, 2012 13:18 UTC (Wed) by sperl (subscriber, #5657) [Link]
As far as I remember SD-Card Specs, it is not necessarily defined, that SD cards always have to return 0xff for erased (=trimmed) blocks...
At least it mention that the behavior may depend on the type of technology (NAND/NOR/...) that is used on the HW-level.
So the behavior of expected return may also be open to implementation for SSDs... (I have not read the spec there though)
TRIM? Posted Dec 12, 2012 21:05 UTC (Wed) by arnd (subscriber, #8866) [Link]
I think the cards can either return all-zero or all-one but have to report in the configuration registers which of the two they do. Of course, you could
in theory reverse all bits in software to get the behavior you want, but that has a nonzero performance impact.
Note that sending the erase command to the SD card can also help performance as it might avoid expensive garbage collection, aside from being faster than writes.
TRIM? Posted Dec 12, 2012 13:32 UTC (Wed) by yann.morin.1998 (subscriber, #54333) [Link]
> When you read from a region that was TRIMed the result is either undefined or all-zeros, whereas when you read from a region that was mtd_erase()d, the result is all-ones.
> So it wouldn't really be useful to make mtd_erase() to TRIM. They do seem similar but they have quite different semantics.
What about combining your catch-erased-sections-and-return-0xFF with TRIMing the underlying storage (if it supports TRIMing)?
Regards,
|
|||||||||||||