Freezing/Disappearing Issues with Indilinx based SSDs (Vertex) explained

[xck]

I will leave this live but I strongly suggest you do NOT do this, see my posts below.

Tony


I dont want to force anyone to do this, so i removed some text. See this as a post for OCZ to reproduce the error and to improve their firmware.

Disclaimer
I have NOT used a Vertex for my test, but another SSD which is very similar to the Vertex and is using the same Controller. Since issues with both SSDs are very similar, eg. disappearing drives, complete system freezes, my feeling is that its a controller (indilinx barefoot) problem which needs to be adressed. I did this on an empty drive (NO OS drive and NO important data on it since you might lose your partition). After the tests you can easily reset your drive using HDDErase 3.1 from ultimatebootcd (http://www.ultimatebootcd.com/).


The Problem explained
We all know that MLC based drives get slower when the are filled. But why is that the case ? For MLC based drives, writes to fresh blocks are much faster than writes to used blocks, because the controller has to delete the used blocks first, before it can write to them, which takes more time.
This results in much slower speeds if the drive as been filled completly because the controller is forced to delete each block before it can write to it. This is a common problem many people know about and accept it. The best way to "reset" a drive is to use HDDErase 3.1 which cleans all blocks and makes them "fresh"
Now onto the issue i (and others) have found with indilinx based SSDs. If you have filled your drive once completly and then do some heavy file creating/file copy actions on the drive, the cache of the controller is full in no time that it cant keep up with deleting/writing new blocks so that Windows doesnt get a reponse from the drive and kicks it out of the system because of timeout issues.
When using the SSD as a data drive, it disappears from the machine completly. When using it as a OS drive it also disappears causing the whole system to "freeze". Only a reboot will bring the drive back, often with damaged partitions or files.
Similar issues have been reported here and on other forums with indilinx based drives, and together with some other people i found a way to reproduce them.

How to test
Dont do this unless you really want to know, i made this post for OCZ to reproduce this error.
Remember: Dont do this with your OS drive or a drive you store important data on, only do this if you SSD is an partition on your machine without any data on it.

1. Fill the SSD completly, for example with h2testw (http://www.heise.de/software/download/ddwl50539) or just copy random files to your SSD to fill it, if you dont want to use h2testw.
2. Quickformat the SSD and repeat step 1 if you want to make really sure all blocks have been filled
3. Use FileCopy-Test (FC-Test) to write random data patterns to your drive (http://www.xbitlabs.com/images/stora...st/fc-test.zip). There are 5 patterns included with the programm.
After starting Fc-Test goto FILE -> OPEN and load the first pattern, which is "ins.ptn" if you have them ordered by name. After loading the ins pattern the ins.ptn tab should be active in the program. click on the most right button to create the test files. As a target you have to select a dir on your SSD (just create one).
After creating the files you have a new tab that says "Filelist1". There should be a button with a document and a red arrow for copying the files, click it. Select "Copy" and also select a target directory on the SSD which has to be different from the one you created your files in.
After copying finished you goto FILE -> OPEN and open the next pattern and repeat the above process. Do this with all 5 patterns. If you did this with all 5 patterns (shouldnt take much longer than 5min) you did 1 run. Perform atleast 3 runs and see if your SSD drive disappears from the system.

My drive and that of many others disappears from the system everytime i do this test. It sometimes takes 3 or 4 runs, but it always happens. After rebooting the system the partition is marked as "RAW" and the data is gone. This is not acceptable for a drive that is being shipped to consumers and the manufacturers have to be made aware of this.

Defrag tools like PerfectDisk 10 or Diskeeper Hyperfast wont help at all with this because they defrag on a file base, while SSDs work block based. Currently there is no way to reset already used blocks instead of HDDErase 3.1 which uses ATA specification commands to reset the whole drive, but there is no software that can do this for unused space of a drive, yet. Even if there was, the SSD should never ever disappear from the system and corrupt the partition/data.
We also found that settings the drive timeout value in the windows registry to a higher value delays the problem, but after 5-6 runs of the above test we can still reproduce this error. It only happens under heavy load though, if you copy files from another, much slower HDD, the problem might not occur, but with FC-Test doing file copy/create operations on the same drive, you will get the error.

This has been tested under Windows Vista in 32 and 64bit.

[Tony]

h2testw is know to have serious issues and can kill ssd drives..DO NOT use this benchmark.


Will add more to this post..i just wanted to get this info up ASAP

[xck]

h2testw is no benchmark. It just creates files on your SSD, why should that kill it ?
Anyway, i edited the first step, after all it doesnt matter how you fill your SSD up, you can also just copy alot of data on it.

[Tony]

It may access the FW, h2testw was written many years ago for HDD and does look to access SSD drives in a way that causes damage or issues. Re flashing the drive will bring it back however.

I suggest you read what we have been advising here, leave 20 to 25% of the drive empty, minimise writes as much as you can to the drive and consolidate free space ...many have tested this and it does work.

IF there was a serious issue in real world use it would be here on the forum, we have guys using the drives every day. You have synthetically looked for an issue pushing the drive with tests the real world does not replicate.

[Tony]

I have a question for everyone. How many of you guys with Vertex fill your drives 100% randomly then sit testing 4 or 5 times looking for an issue?

[xck]

I suggest you read what we have been advising here, leave 20 to 25% of the drive empty, minimise writes as much as you can to the drive and consolidate free space ...many have tested this and it does work.

IF there was a serious issue in real world use it would be here on the forum, we have guys using the drives every day. You have synthetically looked for an issue pushing the drive with tests the real world does not replicate.

Not true. Its not about free space, if about unused blocks. When you use a Windows partition and regulary clean TEMP files or browser cache you will end up with all blocks used after some time, even if you have enough free space left.
If you then install or Copy alot of files to your SSD, you might aswell get this error in real word use. That has happened to a few people already and will happen to more people as their drives blocks all get used once, which will take some time eventually.

[AppleUser]

Check the temps of the controller - my MBP is running hot since installing the SSD.

[Tony]

It may be so, but we are strongly advising people to never fill the drives, to manage their data and look after the drives.

you came here advising people to try at their own risk...which people will do but then come to me for an RMA if it kills there hardware.

I can not allow end users to take risks when you cover yourself saying "try this at your own risk" remember you are on the official support forum for OCZ product.

I think its prudent to realize that the bulk of end users here are aware the drives will slow, they have read many times they will and have taken measures to never come into the situation you pointed out.

there is a simple fix for this...run Steadystate or something similar that creates a large cache. once full the drive will become read only with the cache being flashed on each reboot...

[xck]

It may access the FW, h2testw was written many years ago for HDD and does look to access SSD drives in a way that causes damage or issues. Re flashing the drive will bring it back however.

It "may" ? Sorry, but thats also not true, maybe were talking about different programs here. You just select a folder (indipendet from the drive) to create files in, i also can create the files on a networked folder on my server or a usb stick, how should that access the FW ? It just creates random data.

you came here advising people to try at their own risk...which people will do but then come to me for an RMA if it kills there hardware.

Some file copy tests shouldnt kill anybodys drives, if that was the case you have a product which isnt ready for the market. I have done extensive filecopy tests on mine and after using HDD Erase its back to stock.

I can not allow end users to take risks when you cover yourself saying "try this at your own risk" remember you are on the official support forum for OCZ product.

I added that for your good, but again, if something like this kills the drive you have some serious issues to fix!

I think its prudent to realize that the bulk of end users here are aware the drives will slow, they have read many times they will and have taken measures to never come into the situation you pointed out.

i am NOT talking about slowdons here, i am talking about disappearing partitions with corrupt data which is far more serious than slowdowns which everybody is aware of. It might be true that you wont get into situations like that in real life, but that depends on the usage pattern. If you use the drive for Video Editing / Creating/Copying large files a lot, you might very well get issues. Something like that shouldnt happen, never ever. Do CPU manufactures sell CPUs which arent 100% stable in all situations possible ? No, or do you see CPUs advertised with "dont do 100% cpu load or play heavy games and always leave 20% cpu resources unused" ?
People pay alot of money for these drives, the have to work no matter what is thrown at them!

there is a simple fix for this...run Steadystate or something similar that creates a large cache. once full the drive will become read only with the cache being flashed on each reboot...

Steadystate also has issues, also it doesnt support 64bit operating systems.

[TortureTest]

It may be so, but we are strongly advising people to never fill the drives, to manage their data and look after the drives.

you came here advising people to try at their own risk...which people will do but then come to me for an RMA if it kills there hardware.

I can not allow end users to take risks when you cover yourself saying "try this at your own risk" remember you are on the official support forum for OCZ product.

I can see no reason why any end user would want to perform
this test on his/her drive!
(Only to find out that the drive indeed disappears?)

However, knowing how the problem can be reproduced should
be valuable for OCZ support & Indilinx developers since more
and more incidents of disappearing (Indilinx-based) drives
and lost data are posted in forums.

Keeping some free space on the drive does not help
in the long run. Only TRIM will eventually eliminate
the issue of used-up blocks.

[xck]

yeah i dont want to force anyone to do this, so i removed some text. See this as a post for OCZ to reproduce the error and to improve their firmware.

[Tony]

I agree and I will forward this to our flash engineers...my main issue was the OP covers himself and leaves me to pick up the pieces if drives need RMA.

It comes down to where you post and what you post...here was not the right place to post " try at your own risk"

[Tony]

xck, i know it is regarding vanishing partitions, BUT its only repeatable if you fill the drive 100% over and over. Hence my advice will stop end users seeing the issue.

[xck]

i understand that and changed the parts, sorry for that. basically i just wanted people to notice it

[xck]

xck, i know it is regarding vanishing partitions, BUT its only repeatable if you fill the drive 100% over and over. Hence my advice will stop end users seeing the issue.

If you use you drive as the system drive for several weeks you will reach the point when all blocks hold data. Maybe you still have enough free space because you deleted files from the filesystem, BUT the blocks still hold the data. Only if the filesystems tells the SSD to write to a block that alreasy holds data it knows that it is allowed to delete that block and write new data to it. Other than that it has no connection to the filesystem, so free space doesnt matter much, block fragmentation does. Sooner or later most people will reach the point of "all blocks filled", only way to prevent that is to reset the drive with HDDErase every couple of weeks.