Community
cancel
Showing results for 
Search instead for 
Did you mean: 
idata
Community Manager
5,224 Views

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

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.

0 Kudos
23 Replies
idata
Community Manager
140 Views

When partitioning the drive (after a fresh HDDERASE), don't set the main partition to use all the space available. Leave a few GB of unused space on the drive, and it will use this for better wear leveling.

idata
Community Manager
140 Views

So you can't just shrink the partition by a few GB using the Disk Manager snap-in?

Why do you have to reformat from scratch? You don't want to do an OS reinstall unless you have to after all.......

idata
Community Manager
140 Views

Great. Thanks. I'll try that - but what's the suggested value of "few GB" for 80GB and/or 160GB drives?

idata
Community Manager
140 Views

idata
Community Manager
140 Views

idata
Community Manager
140 Views

Thanks Redux, that explains why a full secure erase is required and why just reducing the partition is not enough.

Quite amazing how much endurance can be added by increasing the spare space.

idata
Community Manager
140 Views

I should note that this method of increasing endurance is instead of TRIM. If you are using TRIM, the effect on endurance is the same as if you had reduced the capacity of your drive to be only whatever you actually have in use, so there is no point in the capacity reduction. i.e. using TRIM with 40GB free on the 74GB (sold as 80GB) drive gives you the same endurance as if you had reduced the capacity to 34GB without TRIM.

idata
Community Manager
140 Views

^ what makes you say that?

idata
Community Manager
140 Views

TRIM affects performance, not endurance. Before flash memory can be rewritten, it must be erased. Without TRIM, the contents of the flash memory are not erased when a file is deleted, it just marks that space as available. This is the same with hard disks as well, and the reason "undelete" apps work and why things like DBAN and Secure Erase are needed to actually remove data from an old drive. With TRIM, the SSD actually erases the flash when the delete command is issued. Without TRIM, the flash needs to be erased on the fly before being rewritten. TRIM moves the erase to the time of deletion to avoid unnecessary delays when rewriting that particular chunk of memory. "Garbage Collection" and manual "TRIM" commands do the same thing - explicitly erase chunks of memory that are marked in the filesystem as being available, so that they're immediately available for writing. TRIM doesn't even really do anything better, it just moves the actual erase function to the time of delete rather than at the time of rewriting data there.

Using a smaller partition increases endurance simply by having less data and more spare space. The larger spare "swap" space allows for less write amplification (how much extra data needs to be written to the flash chips in order to end up with your data properly saved). You have more working area, so you don't need to constantly rearrange everything to fit (which causes lots of extra writing to save a little data).

The Intel firmware will only use the space as spare if it's "clean". In theory, you should be able to shrink the partition then wipe the free space. However, I don't personally know of any utilities that do this (though I haven't really looked either). It should also be theoretically possible for Win7 to TRIM the free space after shrinking a partition, though I don't know if that actually happens. If you have an existing install on your SSD and another disk with some free space, you could always image the existing drive, do the Secure Erase, and restore the image to a smaller partition. This would result in the larger spare space without actually having to go through the install again.

idata
Community Manager
140 Views

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
Community Manager
140 Views

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
Community Manager
140 Views

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
Community Manager
140 Views

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
Community Manager
17 Views

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.

idata
Community Manager
17 Views

Maybe. I think it is likely that there could be a background thread running on the SSD controller which looks for blocks where all clusters are invalid (either due to TRIM or having the logical clusters overwritten), and erases them before they are needed again, but TRIM would return before this thread does the erase.

This is just speculation on my part, but intuitively it makes sense something like this would be done to reduce write performance degradation.

PCoup1
New Contributor I
140 Views

ive just watched that intel presentation, but have absolutely no idea how to increase my spare area.

would anybody care to explain?

idata
Community Manager
140 Views

Use Secure Erase to wipe the drive to a factory-fresh condition, then make a partition smaller than the max size of the drive. The unpartitioned clean space will be automatically added to the spare area. Simply resizing your partition will not clean those freed blocks, so they will not be added to the spare space.

PCoup1
New Contributor I
140 Views

Invisibill, thanks for your reply, however just to be totally clear:

I have a new G2 drive sitting unopened in its anti static bag waiting for the new firmware. Once I've flashed it with the new firmware, boot into W7 setup and arrive at the partition screen. Normally at this point I would make a 50GB partition and use this as my D drive, and the remaining 20GB as my C partition. Windows also makes a 100MB system partition for that bitlocker crap. So, do I need to make 3 partitions? Make a 40GB (for D), a 20GB (for C), and a 10GB for spare area, and then only format C and D and leave the 10GB untouched? I know my figures don't add up to 80GB but theyre going to be roughly whats actually availabile on the drive when I arrive at that screen.

idata
Community Manager
140 Views

No, don't make a 10GB partition. Just leave 10GB of space unallocated on the drive. http://www.sevenforums.com/attachments/installation-setup/10118d1241832267-unalocated-disk-space-aft... http://www.sevenforums.com/attachments/installation-setup/10118d1241832267-unalocated-disk-space-aft... is an example of having some space unallocated (just a random pic I found).

idata
Community Manager
140 Views

But eventually the unallocated space will also be full, right? If you use TRIM or not, you'll still have the problem the SSD will be full of data entirely. The SSD will then undergo some latency issues, because it first needs to erase a block before data can be written to it. Of course this is still a lot faster then mechanic drives. So while using under partition, this will only extend endurance for a bit.

Reply