Maybe one day it'll show up in another machine one day and the firmware can be reflashed/secure erase or something?
How many reallocated sectors did it have?
Maybe it's 'panic locked'? Does that happen to 1200s?
So many questions...
Printable View
Maybe one day it'll show up in another machine one day and the firmware can be reflashed/secure erase or something?
How many reallocated sectors did it have?
Maybe it's 'panic locked'? Does that happen to 1200s?
So many questions...
The last time I had access to the SMART data, it was still at 0 re-allocated sectors. I can try to see if the drive comes back, especially, see if it shows up in parted magic and maybe do a secure erase.
I mean, based on my recent experiences, you may want to try something as simple as unplugging the drive for a few minutes. I don't know if you have physical access to it or not (you may be remote accessing the testing system - I don't recall if you've mentioned it).
If you remove the power to the drive for a while, on powering it back on, or a manual power cycle -- all could all help as simple as a solution as it is.
The drive has been working flawlessly for quite a while, so I'd be surprised if it was really dead.
Maybe it's just gone on strike due to the harsh working conditions :shrug:
I think you will end up hitting it against the wall in more extreme cases.
LOL made my day !
Seems like the SSD obeys quantum mechanics effects. If it is being watched, it reacts differently. Tell you what this whole SF problem is a complete joke. 2 years and still not fixed is pretty laughable.
Surely this is just the effect of SF controller panic mode.
Kingston SSDNow 40GB (X25-V)
364.29TB Host writes
Reallocated sectors : 10
MD5 OK
34.75MiB/s on avg (~12 hours)
--
Corsair Force 3 120GB
01 92/50 (Raw read error rate)
05 2 (Retired Block count)
B1 48 (Wear range delta)
E6 100 (Life curve status)
E7 76 (SSD Life left)
E9 97381 (Raw writes)
F1 129780 (Host writes)
93.96MiB/s on avg (~45 hours).
power on hours : 375
SF provides a number of features that might not always be utilised or configured in the same way. (I.E. temp sensor). LED signals might be combined on one LED to show activity and a fault or they might be on separate LED’s. LED Fault and Activity may be configured as:
50% duty cycle blink, half-second period (ie HIGH 250msec, LOW 250msec, repeat)
50% duty cycle blink, one-second period (ie HIGH 500msec, LOW 500msec, repeat)
50% duty cycle blink, two-second period (ie HIGH 1 sec, LOW 1 sec, repeat)
50% duty cycle blink, three-second period (ie HIGH 2 sec, LOW 2 sec, repeat)
Fault: 100% ON
Activity: 100% ON (valid option only if “ACTIVE” means “PHY Ready”
If the drive has entered a panic condition (or other fault mechanism) the LED activity should behave in one of the ways described above.
A panic condition is related to a serious firmware event. Up to 4 “slots” are available for panic events to be logged. Once all 4 slots are full no further panic condition can be recorded. Personally I would ditch a SSD that entered a panic state.
When the 4 "slots" are all used, how are they cleared?
User fixable or?
It requires specialist hardware.
Your Corsair is dead?
M225->Vertex Turbo 64GB Update:
414.13 TiB (455.34 TB) total
1136.52 hours
8647 Raw Wear
117.97 MB/s avg for the last 64.32 hours (on W7 x64)
MD5 OK
C4-Erase Failure Block Count (Realloc Sectors) at 6.
(Bank 6/Block 2406; Bank 3/Block 3925; Bank 0/Block 1766; Bank 0/Block 829; Bank 4/Block 3191; Bank 7/Block 937)
Attachment 120760
The Corsair is still doing fine on the X58.
It is noticeably slower in 3Gb/s mode but it looks to be stable.
50 hours w/o issues points to that there is something with the drive in 6Gb/s mode or that the drive is having issues with the SnB chipset.
I'll leave it running a few more hours and then I'll update fw + move it back to the SnB rig, if it fails I'll try disabling Hot Plugging.
Attachment 120761
Attachment 120762
The drive just disconnected, so it took almost 51 hours on the X58.
Not sure what triggered it, a lot of activity on this rig but still it shouldn't disconnect.
I'm about to upgrade the fw.
1PB would be around 15890 P/E cycles at the current rate.
Since I had to take my desktop with the H67 down for a few minutes last night, the Mushkin's been running non-stop. So all I can say is that it's more stable on the H67, not completely stable. It might only last 40 or so hours uninterrupted -- I can't really say yet.
In the first few days I had the drive, as the boot device, it only crashed once every 30 hrs. After that I moved it to to a secondary position where disconnects were much more frequent -- every night (and every day). At least for the last two days when I check the system in the morning the drive is still working... that in itself is pretty nice, and if I can keep up the pace I'll pass the Force 3 in writes/host writes in a few days. With all the disconnects over night, then the testing in the much slower laptop, I was only getting about 8 - 9 TB a day.
What part of this H67 board is helping is impossible to say. It could be the disabled per-device hotplugging, or advanced link power management (also in the UEFI) disconnected. It could just be that the sata ports themselves are operating in spec or whatever. Who knows? It might not even be stable yet. I just don't understand what the hell is going on -- but I'll know more in a few days.
Seems to me this app is the most consistent/repeatable usage case for causing SF-2200 failure....
I believe so.
What I find most interesting is that most of the blame is placed on power saving chipset functions, like the ability to partially shutdown the drive. Why would a drive operating at 100% go into a power saving mode? I would assume it would happen when the system is idling, as is the drive -- not when the drive is interleaving writes across many devices -- when the drive uses the most power. It really seems like the drive just "gives up" after a while under endurance loads. So if you want to make sure your SF 2281 is actually stable, the best thing to do is endurance test it for months on end...
If power saving chipset functions are to blame, then a simple solution would be to disable all power saving options possible. This might explain why is so hard to reproduce and why is not affecting all the drives, as this is usually configured differently from one computer to another.
I just realized a funny thing... I have set my laptop on max power profile from the moment I have bought my SSD, as my CPU is undervolted and there is not a significant gain in keeping it running at lower frequencies. It might be a reason why I never experienced any issues
Why don't you enable power savings :)
Using these exact drives, it certainly looks that way.
Would be tempting trying one of the other new gen drives like the m4 but as B.A.T has had no similar experiences...
My drive has been running for almost 3 hours with the new fw (1.3.2) on the original SnB rig, let's see if the new fw makes a difference.
I formatted the drive as a test, next time I might SE the drive.
The fw upgrade reset the power on counter on my drive as well.
Maybe you just solved the SF issue : power saving features !? SF should pay up a big stash :p:
I hope it works out for the Force 3, but I'm more of the opinion that the motherboard matters the most. There may ne some edge cases where stability can be achieved some other way, but it seems like it works with some mainboards and doesn't work with others. A possible exception is if you have ALPM(very few boards have this) and hotplugging disabled in the UEFI... I'd love to test this some more but I'm going to see what happens as is. It's only been 40 hrs on this H67, and only 20 without a reboot. I think the mark to beat is 51hrs stable right? That's the longest number of consecutive hours either 2281 was active.
EDIT
The Avg MB/s has crept up to an astounding 127.28MBs while the wear delta has plunged to 16 from the mid 20's. That's a substantial increase in speed
@bulanula
Power savings (and what not) have been frequently mentioned on the OCZ forums, I've not tried it myself as it hasn't been an issue, until now.
@christopher
51 hours on the X58/ICH10R, I'll have to do a check on the AMD rig though, could be that the first runs were longer...
Like Anvil says the m4 has been performing without a hitch. The same can't be said of the Kingston V+100, but it has behaved nicely for a week now. On the other hand, I'm using AMD chipset but I don't know if that has anything to do with it.
Todays update
m4
590.0843 TiB
2166 hours
Avg speed 88.75 MiB/s.
AD gone from 18 to 13.
P/E 10300.
MD5 OK.
Still no reallocated sectors
Attachment 120772Attachment 120773
Kingston V+100
105.6310 TiB
417 hours
Avg speed 77.03 MiB/s.
AD gone from 98 to 93.
P/E ?.
MD5 OK.
Attachment 120770Attachment 120771
I just noticed BATs SSDLife warning says "too many bad cells and projected lifetime is less than one month".
I'm certain that both are false :yepp: