anon (anon@anon.com) on 1/24/11 wrote:
---------------------------
>MS (ms@lostcircuits.com) on 1/24/11 wrote:
>---------------------------

>>>
>>I don't mean to be the party pooper but let's get some things just re-aligned here:
>>
>>1) TRIM addresses the fundamental problem of NAND flash that you cannot overwrite
>>"used" blocks. Used is the currently official JEDEC terminology to distinguish from
>>"occupied" blocks and used means that the blocks have been programmed but don't
>>have any valid data (since they have been moved elsewhere). TRIM simply causes a
>>pre-emptive erase of these blocks to reconstitute 1 (or 11) values for all cells
>>so that they can be written to without first erasing the block completely.
>
>Trim addresses this problem, but rewrite also has to address the same problem,
>and is much more common to boot. The trend in most storage is to slowly increase the amount of data stored there.
>
This is where I am not so sure. In theory, you are correct, every modern drive moves/refreshes blocks as the error rate increases because of SILC or read disturbance or whatever but there are no provisions of any mandatory erase of the free'd up blocks. Likewise, any data modification will result in an entire block being rewritten somewhere but there is no "erase" for the used block because this was never necessary in HDD technology.


>The window that realtime trim can fit in, between the use of periodic offline/not
>realtime trim and the case of blocks being rewritten, is _not_ very large.
>
>Hardly large enough to be any sort of "game changer" for most workloads even with a really fast trim implementation.
>

>>
>>3) TRIM only works if there are idle cycles, if the drives are subjected to 100%
>>load all the time, then there is simply no time to execute TRIM without inserting
>>idle periods. This is the scenario that Linus referred to, however, outside any
>>extreme case in the enterprise environment, it will happen in a blue moon.
>
>No this is not the scenario, and this does not prevent trim working. If trim was
>a win then it would be worth the small cost to insert trim to make the drive more efficient in subsequent operation.
>
>What Linus is referring to is that *blocks are overwritten after they are freed*.

You can't do this unless you erase them first and that is the whole purpose of TRIM.

>With alarming regularity, actually. Making realtime trim almost completely useless
>work, whether the disk is 100% utilized or 10% utilized.

That's where you have overprovisioning to provide a buffer that is not user-accessible.

>>
>>4) Drives that use de-duplication of data on the controller level like e.g. Sandforce
>>don't necessarily need TRIM because something similar with approximately the same
>>net-effect is already standard operation of the drive.
>
>No. Filesystems don't typically zero blocks when they deallocate them.

Exactly and that was the point.
>
>>
>>5) At least in theory, the number of P/E cycles is the same whether TRIM is used
>>or not. What is different is the time at which the erase is executed, that is, whenever
>>there is some time a which it appears opportune because no other workload is outstanding
>>or whether it is immediately before a re-write. In practice, the change in programming
>>frequency (cluster vs. distributed) will have some effect on the life of the NAND cell.
>
>Active data will certainly incur a higher P/E cost in the course of a drive lifetime
>to manage. I don't know what you're trying to say.
>

Ok, let me try it this way: no matter of whether you erase any block when it is only used but not occupied or whether you just leave it alone and use wear leveling to determine later that this block is next to be rewritten, the common denominator is that the block will have to be erased first.

What is different is the time at which the block is being erased relative to the time at which the block will be re-programmed, which makes some difference with respect to "self-healing" of the oxide layer due to passive leakage and de-trapping of electrons. Granted, in real life this may not make that much of a difference but the effect is definitely there. On the other hand, I think I know what you are trying to say, which is that if you move data around in order to increase the free space, that will incur some extra P/E cycles that would not occur if you were totally operating on an "on demand" basis. In real live, though, especially given the limited retention time of data in NAND (3 months enterprise, 12 months consumer) there is naturally a fair amount of data movement anyway so it probably comes out as a wash. I don't think that there are enough empirical data out there yet to hard-argue one way or the other.
>>
>>6) Any drive experiencing idle cycles during which it is able to perform TRIM will
>>restore steady state by reducing the number of "used" blocks, which, over time will
>>dramatically improve write performance to somewhere between 60 and 80% of a new
>>drive whereas without TRIM, that same write performance will slowly degrade until
>>all blocks are used and then level out at a much lower performance level.
>
>So that obviously depends totally on the FTL and exactly how many blocks were freed,
>how they get reused, how they get trimmed etc.
>
The FTL is just that, the flash translation layer and as such it does not know what data are valid or not but otherwise, yes.