Is TRIM overrated?

[Surly73]

Wow, I learned a lot about trim! Thanks guys! Very enlightening.

1) So, to see if I understood it correctly from your discussion: All deleted data blocks needs to GC to be reused. TRIM marks the deleted data blocks faster, so it allows faster GC? Kind of? Or did I misunderstand?

TRIM is the ONLY way the OS can communicate to the SSD which blocks are to be deleted. Otherwise the SSD only discovers they are no longer needed when the OS overwrites them. The SSD controller can then elect to mark and remap or erase-then-write (which is the performance slowdown which might be observed). Windows logo requirements state that a TRIM call must return in no more than 20 ms. This doesn't mean that the related erase must take place in 20ms, it just means that the call has to return so the OS can get on with things...

2) Another question. You say to leave 40GB empty on each drive in raid. The 40GB should be left out of the raid, it should be "RAW" unpartitioned space. It sounds as if I should do the same, leave out 40GB on my single SSD system disk?

If you're going to do this it should never be written to following a Secure Erase. If the cells have never been written, the SSD "knows" that they are truly free. If the OS writes something to them, even once, and does not use TRIM the SSD will consider them "in use".

Creating a partition, even quick formatting do not actually write to most sectors thus the SSD doesn't know what's going on. This is why I was advocating in another thread that simply repartitioning and reformatting an SSD is not as good as a Secure Erase for resetting everything. The SSD just sees a couple of sporadic writes in various areas of the disk when partitioning and quick formatting - it has no idea that all of the data on the disk is now "deleted".

A true SecureErase clears all of the SSD's mapping tables and tells it that it is truly "empty".

3) Now I am using the entire disk as system disk, it has no 40GB space unpartitioned. What happens if I make sure that I never fill my drive than 80%? Always 20% space is free? Will this benefit the GC, so he has more pages to work with? In effect, if you have an raid, you dont have to leave 40GB unpartitioned but instead you can make sure to always stay below 80% utilization so the raid will always have empty space to use? Is this correct?

If you're using the entire disk, and you have TRIM support, you don't have to do anything. I like to follow a rule of thumb that the drive have at least 20% free space to give it some room to work in, but it will take care of itself just fine if TRIM is used. It's when TRIM is NOT used that some of this workaround crap may or may not make a difference.

TRIM is the right way to do things... I've been running my X25-M G2 with Win7+TRIM for 1.5 years as boot/apps with no special tweaks other than disabling hybrid sleep to reduce unnecessary hiberfil writes and I haven't measured any decrease in performance. Paging, hiberfil, C:\Users are all on the SSD - no issues.

 

[john4200]

Surly73 already answered brutalizer's questions, but I just wanted to add a few general points.

The 40GB free on each SSD is not a special number. Depending on the SSD size and your expected usage, you can use different amounts of overprovisioning. Most SSDs have about 7% reserved space, so if you leave, say 20% space unpartitioned you are roughly quadrupling the amount of unused flash pages (from 7% to about 27%) your SSD will have to work with. How much that helps will depend on the SSD and your usage patterns.

One other thing I wanted to mention -- a general principle that should help with understanding SSDs. All SSDs have an internal mapping table or index. Inside the SSD, the controller has a lot of flash memory pages (usually 4KiB or 8KiB in size) that it can address. But outside the SSD, it must appear as an ATA device, and therefore the SSD responds to commands specifying that it has a certain number of 512Byte sectors (or other size sectors, but most SSDs are still using 512B sectors). The sectors are generally known as logical block addresses (LBA).

To take a specific example, consider a VERY small SSD, with 1MiB of flash, 512KiB erase blocks, and 4KiB page sizes. So the SSD controller has two erase blocks and 256 pages of flash memory it can address, numbered F1 to F256 in our example. However, most SSDs reserve about 7% of space for internal use, so in our example, the SSD will only specify 1904 LBAs available to ATA commands (512Bytes each), numbered L1 to L1904 in our example. That is 1904 x 512B / 1024 = 952KiB. If you bought such an SSD, the box would say it is a 974KB SSD (952 * 1024 / 1000 , rounded down). That leaves 1024 - 952 = 72KiB of reserved flash memory for the SSD controller's internal use only -- 18 flash pages. 18 / 256 = 7% reserved.

We'll assume the SSD comes already secure erased in the box. So all 256 pages of flash memory are unused and the controller marks them "invalid" in its internal index. Since both erase blocks are completely unused, the GC algorithm will pre-erase them. We'll also assume the OS enforces 4KiB aligned writes, so even though the SSD could be sent 512B write requests, we are going to assume they always come in at least 8 sector (4KiB) chunks, aligned to a 4KiB boundary. We'll also skip any partitioning, and assume that the filesystem uses all 1904 LBAs.

Assume you write 8KiB of data to LBAs L1-L16. The SSD may choose to break that up into two 4KiB chunks, and write one chunk to the first flash page F1, and the other chunk to flash page F129 (the second erase block). Don't worry about the reason for doing that (or assume it is for speed, to do the writes in parallel). The controller will update its index, with F1 and F129 no longer marked "invalid", and L1-8 mapped to F1 and L9-16 mapped to F129. But now the SSD controller has a problem, since both of its erase blocks are in use. So at some point the garbage collection (GC) algorithm will read all of the valid data from the two erase blocks, store it in a cache, and then erase, say, the second block, and then write former F1 and F129 data to F129-130. This frees up the first erase block (F1-128), which GC can then erase, preparing it for a later write. Also, the index would need to be updated to map L1-8 to F129 and L9-16 to F130.

Note that at this point, except for F129-130, all other flash pages will be marked "invalid" in the internal index. Although F1 formerly contained data, it is now marked "invalid" since GC moved the data away from F1 and marked F1 invalid. If the user deleted 4KiB of data that the OS stored at L1-8, then a TRIM-capable OS would send a TRIM command to the SSD for L1-8, and the SSD controller would look-up L1-8 and find that it was stored at F129, and so mark F129 as invalid in the index. If the OS does not do TRIM, then it would typically do nothing when the 4KiB was deleted, and the SSD would still think F129 has valid data, even though the OS is not using it anymore.

If the OS were to request a read of L9-16, the SSD controller would consult its index and see that it has L9-16 mapped to F130, and so read the F130 page and return that data for the read request. The next 4KiB write would go to F1, since block F1-128 is pre-erased, regardless of the LBA the OS specified. However, if another 4KiB write came in before GC had time to work, then the SSD would need to read, say, F1-128, store it in a cache with the new 4KiB data, erase block F1-128, then write F1-128 again with the new 4KiB data. That read-modify-erase-write cycle is slow, particularly the erase step. Which is why GC tries to keep a supply of pre-erased blocks ready to go.

Okay, that was longer than I intended. Hopefully it was clear enough.

 

[Aesma]

If we take into account that current 22nm flash memory has 3000 write cycles, we can understand with your example that a small SSD like that will die very quickly because almost each write will be amplified.

What do you think could be the size of the index ? It must be several bits per page (to store adress/LBA, and state (data/invalid/free), maybe wear too), so quite big.

 

[john4200]

If we take into account that current 22nm flash memory has 3000 write cycles, we can understand with your example that a small SSD like that will die very quickly because almost each write will be amplified.

What do you think could be the size of the index ? It must be several bits per page (to store adress/LBA, and state (data/invalid/free), maybe wear too), so quite big.

An SSD with 1MiB of flash was not intended to be a realistic example, just something to demonstrate the basic principles. In reality, even an SSD with only 40GiB of flash would have a lot more reserved flash to work with -- 7% of 40GiB comes out to about 3GB, or about 5600 erase blocks of 512KiB each. So there is a decent amount of extra space for the GC and wear-leveling to play with. Of course, not all of the unused flash would necessarily be collected into the same erase blocks at any given time -- that internal defragmenting is where things get messy and GC will perform better if it has even more extra space to work with.

As for the size of the index, consider a 120GB Intel 320 SSD. I think that it uses 8KiB page sizes, and has 120GiB of flash (not counting the extra parity flash, probably 12 or 16GiB worth on the back of the circuit board). 120GiB / 8KiB = 15,728,640 pages. Since 2^24 = 16,777,216 , a page number can be stored in 24 bits. If 512B LBAs are kept together in page size chunks (16 LBAs per page), then the LBA to page map would require 45MiB. Add in one bit per page for invalid flag, 15728640/8/1024 = 1920KiB. All of it should fit in about 47MiB, so a 64MiB cache would be sufficient. And indeed, the Intel 320 has a 64MiB Hynix Mobile SDR 666Mhz H55S5162EFR-60M memory chip on the circuit board. Of course, this is just a rough estimate. I think even the 600GB 320 SSDs get by with 64MiB of cache, so they are probably using some tricks and/or chunking the map together in larger chunks than the page size.

 

[Surly73]

If we take into account that current 22nm flash memory has 3000 write cycles, we can understand with your example that a small SSD like that will die very quickly because almost each write will be amplified.

For those paranoid about SSD endurance: http://www.xtremesystems.org/forums/showthread.php?t=271063

My X25-M G2 has been in my main rig since March 2010. The only system change to accomodate the SSD was to disable hybrid sleep - sleep and hibernate are both enabled, the hiberfil and swapfile are on the SSD, as is C:\Users. My games are installed to HDD (my steam dir is bigger than the whole SSD). My media wearout just dropped from 99 to 98 a week or two ago. I generally have about 25% free on the device but it is fully partitioned. TRIM is operational with Win7 in AHCI mode + RST drivers.

Am I worried about my SSD wearing out? Not in the slightest. The gain in speed, responsiveness and multitasking has been worth every penny. Whenever I'm on a non-SSD system it's painful.

 

[drescherjm]

I think the difficulty people have with that is you can not do a secure erase on the OS drive and since most users have their SSD as the OS drive it is more work. You can however plug the SSD some other PC, install intel toolbox and do the secure erase from that.

 

[Surly73]

The Secure Erase option in Intel's SSD Toolbox, is that not a 'real' secure erase? I'm suspicious, as no-one seems to have mentioned it.

What do you mean?

My understanding is that, despite it's name, SecureErase isn't so much about "security" (like DBAN) as it is about doing a full reset/wipe of all of the mapping tables in the SSD controller. Every cell is marked discarded and a candidate for erasure, all remappings are deleted, and everything starts like it was fresh from the factory. I don't know for certain if all cells are erased during the "SecureErase" as well. It would be nice, but you'd be waiting a little while.

As I've mentioned in one of these SSD threads, erasing a partition is a couple of writes. Quick formatting is also just a couple of writes. This does NOTHING to reset the SSD's tables back to their original state even though it looks "empty" from the OS. If you ran DBAN on an SSD the SSD controller would think that every cell was valid and in use because it was just written to. It would be anything but "fresh" if you went back to load a new OS.

I would trust the SecureErase in the Intel toolkit to be a full reset - at least on their SSDs.

 

[john4200]

If you ran DBAN on an SSD the SSD controller would think that every cell was valid and in use because it was just written to. It would be anything but "fresh" if you went back to load a new OS.

While this is true in general, I have read that some SSDs are smart enough to recognize a flash page as invalid if it has a certain pattern written to it (usually either all 0's or all 1's, depending on the flash). If you knew what pattern to write, and then wrote it to all LBAs, then with some SSDs that should achieve a similar result as secure erase.

However, even if you could do it, it is clear that you should NOT do it. Why waste the time (even an SSD takes a while to write all LBAs) and the extra program/erase cycle, when you can just do a secure erase and achieve the same result quicker, and with less wear on the flash?

One other thing is that some SSDs (the Intel 320 is one), encrypt all data stored in flash memory, and keeps the encryption key itself. When you do a secure erase, all it has to do is discard the encryption key and then the data is irrecoverable, even if someone were to try to read each flash memory chip and reconstruct the data. Of course, the controller also discards its mapping data and marks all pages invalid, as well.

 

[Surly73]

While this is true in general, I have read that some SSDs are smart enough to recognize a flash page as invalid if it has a certain pattern written to it (usually either all 0's or all 1's, depending on the flash). If you knew what pattern to write, and then wrote it to all LBAs, then with some SSDs that should achieve a similar result as secure erase.

I wouldn't count on it. Furthermore if you were doing this within a filesystem the payload area of the sector/cylinder may be all 1s but all of the other sector data would not be. (Just like sending a file of all 1s doesn't mean your ethernet frames are all 1s. Frames, datagrams, packets all still have headers and other overhead)

It might be true, but I wouldn't count on this in "the real world" when SecureErase is an option. I believe all 1s is what you're thinking of, and I'm not sure if DBAN can even write all 1s.

Even if it succeeded, this method may indeed mark all/most sectors as invalid/stale/blank/available (whatever) but that doesn't mean it would undo all of the remapping tables pertaining to the disk.

However, even if you could do it, it is clear that you should NOT do it. Why waste the time (even an SSD takes a while to write all LBAs) and the extra program/erase cycle, when you can just do a secure erase and achieve the same result quicker, and with less wear on the flash?

One other thing is that some SSDs (the Intel 320 is one), encrypt all data stored in flash memory, and keeps the encryption key itself. When you do a secure erase, all it has to do is discard the encryption key and then the data is irrecoverable, even if someone were to try to read each flash memory chip and reconstruct the data. Of course, the controller also discards its mapping data and marks all pages invalid, as well.

Yep - this covers security AND the case for 'factory reset'.

 

[john4200]

It might be true, but I wouldn't count on this in "the real world" when SecureErase is an option. I believe all 1s is what you're thinking of, and I'm not sure if DBAN can even write all 1s.

I didn't mean DBAN, although I suspect it can. It is quite easy to write all 1's or 0's to a drive -- in linux you can do it with one command line using dd.

I was not "thinking of" all 1's. As I wrote, the pattern would depend on the SSD controller, assuming it can recognize a certain pattern as equivalent to an erased page. But as I wrote before, I do not recommend it. The secure erase function should be used instead.

 

[InvisiBill]

My understanding is that, despite it's name, SecureErase isn't so much about "security" (like DBAN) as it is about doing a full reset/wipe of all of the mapping tables in the SSD controller. Every cell is marked discarded and a candidate for erasure, all remappings are deleted, and everything starts like it was fresh from the factory. I don't know for certain if all cells are erased during the "SecureErase" as well. It would be nice, but you'd be waiting a little while.

Secure Erase is indeed about security. It's actually been a part of the ATA standard for about 10 years now. It's essentially a DBAN-like function built into the firmware of the drive. On platter drives, it will actually overwrite the entire drive (even areas not normally accessible to the user, which makes it better than DBAN and other software solutions). It should also be slightly faster than DBAN, since it's all internal to the drive rather than having to actually push all those bits over the ATA interface (though it is still overwriting every bit of the drive, so it'll definitely take a long time).

On an SSD, Secure Erase works by issuing an erase command to every block of the flash (NAND flash has an erase time of a few milliseconds). This permanently gets rid of any data on the drive, as well as leaving every block in an immediately-writable state (so you don't have to do the slow cache-then-erase-then-write for any writes).

80GiB SSD / 512KiB erase blocks = 163,840 blocks. At 2ms erase time, that would be only 327.68 seconds (5.46 minutes) to sequentially erase every single block. The X25-M G2 has 10 parallel channels, so even if it was only able to do 1 block on each channel simultaneously, that would result in about 33 seconds to wipe the whole thing. If you're the type to get raided by the FBI and would normally keep a degausser mounted on your HDD, you should switch to an SSD with Secure Erase enabled and ready to be activated at a moment's notice. =)

Also, some testing seems to indicate that quick-formatting an SSD in Windows 7 does actually erase all the blocks. If you're completely wiping the drive and starting over, you might as well Secure Erase to be sure, but quick-formatting has been shown to restore performance to used partitions.

 

[Surly73]

Secure Erase is indeed about security. It's actually been a part of the ATA standard for about 10 years now.

Yes, that is it's origin. The point I was trying to make is that in SSD-land, SE is more relevant to the average user as a "full factory reset" than as a security tool. If I was doing a complete rebuild/reinstall of my main rig there's no way I would bother to Secure Erase an HDD - I would just quick format and go. I would Secure Erase my SSD, however, to get the "full factory reset" functionality.

Also, some testing seems to indicate that quick-formatting an SSD in Windows 7 does actually erase all the blocks. If you're completely wiping the drive and starting over, you might as well Secure Erase to be sure, but quick-formatting has been shown to restore performance to used partitions.

I'd like to see links to that, as I'm not sure how it is possible. Despite the OS seeing a drive with no partition as "empty", for instance, the HDD/SSD only rewrote a couple of sectors to accomplish this. Ditto with a quick format. Even a full format will do a bunch of writes, but won't reset all of the remapping tables or re-jig wear leveling within the drive.

Frankly, a full format might be the worst thing you could do for an SSD. You're basically telling the SSD that every sector on the drive was freshly written and contains important data instead of letting the SSD controller work with the assumption that every block which wasn't written is "invalid" and can be reused at any time whenever needed.

Despite SE being the closest thing to a factory refresh it isn't 100%. Even with everything wiped clean some cells have more wear than others. If an SSD owner has had a single installation of Windows on an SSD for 2 years, there are files which were written once and never rewritten. Those cells/blocks have only been used once compared to far more active areas of the drive. I would expect (but don't have the knowledge to confirm) that top notch SSD firmware would take advantage of a Secure Erase to re-evaluate wear leveling. Receiving a Secure Erase command is a "here's your chance" message to the SSD controller to put the most worn blocks out of rotation for a while, for instance.

I am also hoping that top notch SSD controllers also have algorithms to move stale data around every so often to improve wear leveling. Without a real white paper from a major vendor I'm not sure that we'll ever know.

 

[drescherjm]

I'd like to see links to that, as I'm not sure how it is possible. Despite the OS seeing a drive with no partition as "empty", for instance, the HDD/SSD only rewrote a couple of sectors to accomplish this. Ditto with a quick format. Even a full format will do a bunch of writes, but won't reset all of the remapping tables or re-jig wear leveling within the drive.

The OS could have trim on the format command, however I would like to see that confirmed.

 

[brutalizer]

If you're using the entire disk, and you have TRIM support, you don't have to do anything. I like to follow a rule of thumb that the drive have at least 20% free space to give it some room to work in, but it will take care of itself just fine if TRIM is used. It's when TRIM is NOT used that some of this workaround crap may or may not make a difference.

My problem is that I am running Solaris 11 Express for ZFS, and Solaris does not have TRIM.

So, to help Solaris without TRIM, could it be good to:


1) Make sure that the drive always has 20% free space


2) Repartition my 240GB Vertex 3 drive and only use 200GB. And leave 40GB for GC. But I would do a clean erase before reinstall of Solaris 11 Express.

But if I leave 40GB for GC, then the SSD will overwrite those bits - how can the SSD know that these bits are GC area? I dont have TRIM, so the SSD will not know that these 40 GB is a GC area?




So to recap, exactly what advantage does TRIM give? I mean, it seems that TRIM marks erased blocks so GC can prepare them them in advance? Without TRIM the SSD will never know in advance? With TRIM, the SSD will know in advance? And what does this knowledge in advance give the SSD? It gives the SSD knowledge to store new bits without having to first erase the blocks, similar to decrease fragmentation? ZFS does not write out data at once, it collects data for some second, and finally write out all data in one sweep, to decrease fragmentation. Is this what TRIM does? Mark blocks as erased so SSD can write bits in a large area, instead of splitting the write into many smaller areas?

TRIM = collect many small writable areas to one big area?

 

[drescherjm]

2) Repartition my 240GB Vertex 3 drive and only use 200GB. And leave 40GB for GC. But I would do a clean erase before reinstall of Solaris 11 Express.

But if I leave 40GB for GC, then the SSD will overwrite those bits - how can the SSD know that these bits are GC area? I dont have TRIM, so the SSD will not know that these 40 GB is a GC area?

The SSD will not know that the 40GB is able to be discarded without you doing a secure erase on the whole drive.

TRIM = collect many small writable areas to one big area?

No. That sounds more like GC than TRIM however GC does not care about 1 big area.. I would read the last few posts on this thread. Surly73 and john4200 (among others) did a very good job of explaining how TRIM works.

 

[InvisiBill]

I'd like to see links to that, as I'm not sure how it is possible. Despite the OS seeing a drive with no partition as "empty", for instance, the HDD/SSD only rewrote a couple of sectors to accomplish this. Ditto with a quick format. Even a full format will do a bunch of writes, but won't reset all of the remapping tables or re-jig wear leveling within the drive.

The OS could have trim on the format command, however I would like to see that confirmed.

http://www.anandtech.com/Show/Index/2865?cPage=9&all=False&sort=0&page=2

As expected, performance goes down as the drive fills up. The second run is much slower than the first.

Now look at the two runs if we format the drive in between. The format under Windows 7 triggers a TRIM of all invalid data, meaning all the jibberish we generated in the first run is gone and the second run now runs at full speed:

I haven't tested it myself, but I have no reason to doubt Anand here.

Despite SE being the closest thing to a factory refresh it isn't 100%. Even with everything wiped clean some cells have more wear than others. If an SSD owner has had a single installation of Windows on an SSD for 2 years, there are files which were written once and never rewritten. Those cells/blocks have only been used once compared to far more active areas of the drive. I would expect (but don't have the knowledge to confirm) that top notch SSD firmware would take advantage of a Secure Erase to re-evaluate wear leveling. Receiving a Secure Erase command is a "here's your chance" message to the SSD controller to put the most worn blocks out of rotation for a while, for instance.

Performance-wise, it should be exactly the same as brand new after a Secure Erase. Extra write cycles on a block of flash shouldn't affect their performance, just the remaining lifespan of that flash. Even if the wear-leveling algorithm is as simple as "write to the flash with the lowest number of write cycles", it should proceed to use the "freshest" blocks first.

The biggest issue I can see with this is putting your fairly-static Windows files on the first half of the drive and your dynamic user data ending up on the second half. If you wipe it and reinstall, the static Windows files would be the first ones written and end up in (approximately) the same less-used blocks. I'm not sure there's any way around this though, unless you make the SSD controller aware of which data is static and dynamic, or you manually alter how the files are written to the drive (write a huge dummy file (to use up and temporarily block those fresh areas) before reinstalling Windows, etc.).

I am also hoping that top notch SSD controllers also have algorithms to move stale data around every so often to improve wear leveling. Without a real white paper from a major vendor I'm not sure that we'll ever know.

I think I remember hearing about some doing that, but yeah, we probably won't ever know 100% for sure. As the flash manufacturing process gets smaller, the transistors leak more easily, so it will also be more important for old data to get rewritten so that it doesn't get lost.

 

[Metaluna]

Only the drive engineers know for sure, but I think it's pretty much a given that they *have* to move static blocks around for the wear leveling to be effective.

Imagine you have a drive where you install your OS and apps and fill up 95% of the drive, leaving just enough room for swap and temp files. If you never moved the static blocks around, you would kill the remaining flash sectors pretty quickly, even with overprovisioning.

 

[Surly73]

The OS could have trim on the format command, however I would like to see that confirmed.

It could. That would make a "quick format" something like 1/ write these 20 sectors 2/ TRIM the other billion. I exaggerate, but I think the concept would be correct.

 

[Surly73]

2) Repartition my 240GB Vertex 3 drive and only use 200GB. And leave 40GB for GC. But I would do a clean erase before reinstall of Solaris 11 Express.

But if I leave 40GB for GC, then the SSD will overwrite those bits - how can the SSD know that these bits are GC area? I dont have TRIM, so the SSD will not know that these 40 GB is a GC area?

In your scenario it would "know" because after a Secure Erase you never wrote to that 20% of the drive. That's why Secure Erase is a fundamentally required operation before switching to your 20%+ scheme. I don't know that this "leave 20% free" scheme ACTUALLY works, but there's lots of threads where people say it should work.

So to recap, exactly what advantage does TRIM give? I mean, it seems that TRIM marks erased blocks so GC can prepare them them in advance? Without TRIM the SSD will never know in advance? With TRIM, the SSD will know in advance? And what does this knowledge in advance give the SSD? It gives the SSD knowledge to store new bits without having to first erase the blocks, similar to decrease fragmentation? ZFS does not write out data at once, it collects data for some second, and finally write out all data in one sweep, to decrease fragmentation. Is this what TRIM does? Mark blocks as erased so SSD can write bits in a large area, instead of splitting the write into many smaller areas?

Fragmentation is completely unrelated to TRIM. TRIM is about increasing speed and improving wear leveling. When the SSD knows which cells don't contain data it can pre-erase them in the background so the system doesn't need to wait for the erase before writing. Assuming the SSD has enough "reserve" blocks to handle a host's volume and rate of writes it should still be able to defer erasure so that it doesn't block a write operation but giving the SSD the information it needs to properly manage resources can ONLY help.

 

[Surly73]

Performance-wise, it should be exactly the same as brand new after a Secure Erase. Extra write cycles on a block of flash shouldn't affect their performance, just the remaining lifespan of that flash. Even if the wear-leveling algorithm is as simple as "write to the flash with the lowest number of write cycles", it should proceed to use the "freshest" blocks first.

Agreed, it isn't a performance matter, just a service life/wear leveling matter. If we assume that a Secure Erase doesn't totally labotomize the SSD controller (i.e. it still knows wear levels of cells) then the SSD designers could design any algorithm they want for reuse. If there's a large "difference" between min and max wear they could elect to use most-worn first after a Secure Erase assuming that it's an OS install and stale data will be the first written... These are pretty smart people, all kinds of things may or may not be done.

I haven't checked in recently, but some people are purposely causing wear on their drives and observing the "wear out" indicators and wear difference indicators. http://www.xtremesystems.org/forums/showthread.php?t=271063

The biggest issue I can see with this is putting your fairly-static Windows files on the first half of the drive and your dynamic user data ending up on the second half. If you wipe it and reinstall, the static Windows files would be the first ones written and end up in (approximately) the same less-used blocks. I'm not sure there's any way around this though, unless you make the SSD controller aware of which data is static and dynamic, or you manually alter how the files are written to the drive (write a huge dummy file (to use up and temporarily block those fresh areas) before reinstalling Windows, etc.).

Yep - the only way is to design your algorithms to move stale data and not worry about how dynamic it is or come up with other "guess work" algorithms to try to encourage "fresh install" static data onto worn cells.

Clearly a stale data refresh algorithm is more universal and would work out better in the end.

I think I remember hearing about some doing that, but yeah, we probably won't ever know 100% for sure. As the flash manufacturing process gets smaller, the transistors leak more easily, so it will also be more important for old data to get rewritten so that it doesn't get lost.

Only the drive engineers know for sure, but I think it's pretty much a given that they *have* to move static blocks around for the wear leveling to be effective.

Imagine you have a drive where you install your OS and apps and fill up 95% of the drive, leaving just enough room for swap and temp files. If you never moved the static blocks around, you would kill the remaining flash sectors pretty quickly, even with overprovisioning.

Exactly. I remember that issue starting a thread here a month or two ago. I wish we had some concrete info from the different major manufacturers on whether they move static data BOTH for wear leveling and to fight normal cell discharge.