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]

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.

[PCoup1]

Sorry, that is what I meant. Say I get 70GB of space in the partition screen. Make a 40GB and a 20GB, format the 40GB and use as D, and format the 20GB and use as C, leave the other 10GB unallocated?

I heard in that Intel presentation that increasing your spare area gives you a performance increase. Is this all I have to do for that also?

[idata]

TRIM works by removing that stale data that's left in the pages. With TRIM, deleting data actually results in pages getting erased, to avoid the delays involved in rewriting those pages in the future. It actually keeps the flash from getting full of old stale data.

Your partition needs TRIM because the filesystem is isolated from the physical drive. Without TRIM, the drive's controller doesn't actually know which pages are still holding valid data and which ones are holding data from files that have been deleted. It must retain them all, as it only knows that they all hold data.

However, the spare area is not partitioned at all. My assumption is that the controller knows this chunk of space can be erased once it's done being used. As soon as it's done acting as a temporary storage spot and the data has been saved to other flash chips, it can immediately erase those spare chips so they're ready for instant writing next time they're needed.

I'm going to use nice round numbers for an example, but you get the idea. If you were to completely fill up your 80GB SSD, then delete a 10GB file, you'd have 70GB of data, 10GB of free space with stale data in the pages, and 5GB of fresh spare area. Now if you write a new 5GB file to the drive, it should use the spare area. Now you have 75GB of data, 5GB of free space with stale data in the pages, and 5GB of spare area with stale data in the pages. If you were to immediately write another 5GB file, it would have no choice but to use pages that already had old data in them, and it would be slower due to having to cache-erase-rewrite to save the new data.

Let's do the same example with a slight change. You again completely fill up your 80GB SSD, then delete a 10GB file, giving you 70GB of data, 10GB of free space with stale data in the pages, and 5GB of fresh spare area. Again you write a new 5GB file to the drive, using the spare area. Once more you have 75GB of data, 5GB of free space with stale data in the pages, and 5GB of spare area with stale data in the pages. At this point, the controller can use the wear-leveling algorithm to remap the flash with the just-written 5GB of data as being part of the partition's space, and the 5GB of space that previously held those sectors is remapped as spare area. The controller knows that it just remapped that location to the other flash chip, so this flash chip's data isn't needed anymore and can be erased (making it ready for writing as soon as it's needed).

In the partitioned area, the controller doesn't know what's good data and what isn't, it just knows if there's a page of data written there. The spare area is handled by the controller and doesn't permanently store user data. Once the temporary data is saved in another flash chip, it no longer needs the first instance of the data so the original chip can be erased. That means that the controller can clean up after the first 5GB file is written, giving you 75GB of data, 5GB of free space with stale pages, and 5GB of fresh spare area. As long as you give it time to clean up and don't go beyond the amount of spare area available, it seems like it should be able to have the spare area fresh and ready for writing most of the time. It could get fragmented due to remapping, resulting in some operations needing a slower cache-erase-rewrite, but it should be able to keep a pretty good chunk of flash ready to be written. The larger your spare area, the more headroom you have for shifting things around.

[PPapp]

How would one do this with a RAID 0 setup? Let's say I'm using 2x80GB G2 drives, which have not been used before, in a RAID 0 setup... would you simply set the primary parition to, for example, 120GB?

Thanks.