how can I increase endurance of X25-M by slightly lowering it's capacity?

[idata]

On another forum (http://c0t0d0s0.org/archives/5993-Somewhat-stable-Solid-State.html http://c0t0d0s0.org/archives/5993-Somewhat-stable-Solid-State.html) I've read this:

"Intel says that you can increase endurance of the X25-M by 3.5X by lowering its capacity slightly".

Anyone knows if it's really the case and how exactly it's done?

Thanks.

[idata]

The amount of misinformation about TRIM is kind of incredible (but not really, it is kind of typical for new technologies).

TRIM does NOT cause blocks to be erased immediately. It just marks them as unassigned in the Logical->Physical cluster mapping, so that the firmware knows that the next time the physical block needs to be erased for a read/erase/write cycle the TRIMmed clusters within the block do not need to be re-read and re-written (just erased). This results in a performance advantage because the TRIMmed clusters don't need to be re-read and re-written, but even more of a endurance advantage because by not rewriting ALL the clusters in the block when it goes through a read/erase/rewrite cycle there are free clusters in the block after this cycle that can be re-used for future writes, making it take longer before another read/erase/rewrite cycle is needed. Which is pretty much the same thing that preventing some logical blocks from ever getting written by making your partition accomplishes, only TRIM can do it more aggressively and more conveniently.

I strongly recommend you read http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=1 http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=1, especially pages 8-11.

[idata]

Hi all, this is exactly the question I have been trying to ask but no1 replied to my thread. /thread/8427?tstart=30 http://communities.intel.com/thread/8427?tstart=30

Anyway, can I assume that if I am using Windows 7 with TRIM, there is no need to "under partition" ?

However if I am going to use the SSD for OS X in a mac, "under parition" is the way to go?

FInally, I have a new drive OEM from ebay and I am waiting to update the firmware before installing the OS, do I need to do a HDDerase before the parition and OS install?

[idata]

Read page 10 of your own link. http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=10 http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=10

"The third step was deleting the original 4KB text file. Since our drive now supports TRIM, when this deletion request comes down the drive will actually read the entire block, remove the first LBA and write the new block back to the flash:

The TRIM command forces the block to be cleaned before our final write. There's additional overhead but it happens after a delete and not during a critical write."

That states that TRIM does move the erase operation (reading the existing data in the block to cache, erasing the block, and rewriting the pages which contain data) to the time of delete. However, http://www.anandtech.com/storage/showdoc.aspx?i=3667&p=1 http://www.anandtech.com/storage/showdoc.aspx?i=3667&p=1 states that the controller is always keeping track of every single bit, and TRIM allows it to stop worrying about the bits from deleted files as you describe.

I'm not sure which to believe. Since it's isolated from the software filesystem, it makes sense that the SSD itself wouldn't know if a page was no longer valid data unless the filesystem specifically told it so (i.e. TRIM). But if it really does keep track of every single bit, then once you've written to all the pages on a non-TRIM SSD, then every single write - no matter how small - would involve rewriting a whole 512KB block of data during the cache-erase-rewrite cycle.

It seems like it should be easy to test for this, as a 4KB write operation would actually be writing 512KB, and an 8KB write operation would also be writing at least 512KB, and 16KB would be at least 512KB, etc. I can't seem to find any benchmarks testing this though. It seems like this bottleneck would be blatantly obvious with a few test runs with different size blocks. I would think they would all take the same amount of time to write, since they're all going to end up writing 512KB rather than 4-16KB or whatever block sizes you were testing. The only issue I can see complicating this would be wear leveling splitting an 8KB write over 2 different 512KB blocks, the 16KB write over 4 different 512KB blocks, etc. If so, then the write amplification would increase proportionally to the size of the test file, rather than the result of almost always having 512KB written (and thus the same benchmark time) whether the test file is 4KB or 400KB.

If the controller is actually keeping track of every bit and TRIM allows it to forget about the deleted bits, then it should result in fewer pages being written in each erase cycle, which means less wear on the flash. If TRIM is simply moving the cleanup from pre-write to post-delete, then the process itself isn't changing, only the time, so endurance wouldn't be affected at all.

[idata]

I am fairly certain this is misstated, and TRIM does not actually erase the block immediately for 2 reasons:

1. It is impossible to do so without doing an extra read and rewrite of any unTRIMed clusters in the same block, which would make TRIM yield degraded performance rather than improved.

2. Windows 7 logo requirements state that the TRIM command, if implemented, must return in under 20ms in all cases. This would not be the case if you were actually erasing a very large file when the delete TRIMed it. (Source: http://download.microsoft.com/download/5/E/6/5E66B27B-988B-4F50-AF3A-C2FF1E62180F/COR-T558_WH08.pptx http://download.microsoft.com/download/5/E/6/5E66B27B-988B-4F50-AF3A-C2FF1E62180F/COR-T558_WH08.pptx)

As to your other point about this implying that once a drive is full, every write causes a read/erase/rewrite cycle: this is why all decent SSDs ship from the factory with some spare area that you can't partition. According to the Intel presentation, this spare area is 7% of the drive on the X-25M. So at any given time, even if you have written to all 74.4GB of logical clusters that are available to you at least once, there is 5.6GB of clusters that either have not been rewritten since the last erase or have data that is no longer in the logical->physical cluster mapping (which gives the total of 80GB). And the firmware can pick whatever block has the largest portion of this 5.5GB for a read/erase/rewrite cycle when needed. In a synthetic worst case scenario where you manage to defeat the wear leveling algorithms and get that 5.6GB spread almost perfectly even across all blocks, this means each block has 36-40KB (average 38.54) that doesn't need to be rewritten, so your random write performance will be degraded by a factor of 512KB/38.54KB ~= 13.3x.

[idata]

I think we're both right here. I've been reading more, and due to the separation between the filesystem and the physical device, it seems the SSD would be forced to maintain the invalid pages as well. I read that statement from Anand about immediate erasure early on, and it sort of got stuck in my head that's how it worked. Page 9 of that PowerPoint mentions "enhancing device wear leveling by eliminating merge operation for all deleted data blocks", which sounds like your description of letting it forget about the stale pages. However, the same page mentions "making early garbage collection possible for fast write" also. I don't know that it's directly triggered by TRIM, but it sounds like this does actually go through and preemptively erase (cache-erase-rewrite) stale pages to allow for undelayed writes when needed.