OCZ Vertex bashes users with Blue Screen of Death OCZ forum users are up in arms about their high-performance Vertex 3 flash drives causing Windows PCs to go into a blue-screen-of-death (BSOD) state, and further angered by OCZ's unconcerned response. Poster GymRatZ told us: "I spent about 3 days attempting to get it recognised by Windows (7) 64 for install. Eventually after …
As far as I'm aware, MTBF ratings for drives, like most electronic devices, is solely limited to the physical device and not firmware or software of any kind. Whether MTBF is a particularly useful statistic anyway is another matter entirely.
Of course, manufacturers could define a greater scope for the MTBF system, but since this introduces more risk it, unsurprisingly, does not seem to be in their best interest for the purpose of shifting physical goods ...
seems right to me,
a drive that has firmware that is exactly as the manufacturer designed it but happens to be incompatible with certain combinations of other hardware or bios's cannot be added as a failure when it is returned to be exchanged for a different drive.
the drive itself has not failed, it has merely been found to not be compatible that users hardware
What does that tell you about the system? Either that the (SATA) drivers, parts of the core OS, or both, are badly broken. It's notoriously difficult to protect the OS from faulty drivers, … but SATA? That's a pretty core system component. I guess those drivers are written by the Mainboard or chipset manufacturers rather than Microsoft, but I'd still hope that they've been pretty well tested … and it is a bit disappointing that Windows (7 presumably) is still unable to protect itself from rogue drivers. Once the system has booted, even if its system disc failed or started behaving otherwise strangely I would just expect some things to stop working, but certainly nothing to crash. So I would probably blame jointly the motherboard vendor and OS vendor for these crashes, not OCZ. Sure, the OCZ drives may be doing something odd on the SATA bus, but that should never be able to bring down the system.
I wonder how these devices behave when used with systems containing the same hardware running Mac OS, Linux, FreeBSD, NetBSD, … has anybody seen any reports of “BSOD” equivalents (kernel panic etc.) there with these drives?
You expect the OS to be able to handle losing access to drivers, pipes, swathes of virtual memory (assuming that there is a pagefile out there) etc. and carry on working? To what purpose?
In this type of situation, with perfect error recovery, chances are the OS would be running but totally non-functional as everything it would try would result in an error. In reality everything would just crash.
You want to try it? Put any OS of your choice on a USB drive, boot it, do some work, then pull the USB drive. See how much more work you can get done before the whole system crashes and burns.
Sorry to disappoint you, but I was administrating a router that often kicked drives out of RAID5, two to be exact.
The only thing that wasn't working in this Linux installation after loosing disk access was log on. Firewall, bandwidth shaping, routing was working as if nothing has happened (sometimes weeks at a time). So yes, there IS a point to try to recover gracefully after loosing disk access.
How do you propose the OS does anything but crash if the failed drive is the one with all the operating system files on and/or the one with the swap file/partition on?
In a system with an SSD, both usually apply.
Sure, you could have an OS that loads everything it might possibly need into RAM but that's going to waste a lot of RAM.
Honestly, this is like complaining that an OS crashes because the memory or the CPU explodes.
If the firmware plays a part it is unlikely that the SATA drivers are the issue - the firmware must be at fault.
Moreover SATA drivers are not written in the main by motherboard mfrs but by chipset designers in the majority of cases Intel or AMD, and they are not likely to produce cr*p drivers.
OCZ drives based on Sandforce controllers have had compatibility issues with certain newer versions of Intel storage drivers for some time (even the previous generations).
Most likely this relates to Sandforce's so called "secret sauce" which enables their controllers to get such extraordinarily high IO/sec results despite using similar components to everyone else.
They apply a type of compression algorithm to the data written to the drive to reduce the time to read/write and theoretically increase lifetime (conversely writing large quantities of incompressible data e.g. JPEGs will kill one of these drives in zero time - they are only good for OS/software).
I note that Corsair which also sells the same Sandforce drive branded as the "Force" series (essentially all these manufacturers offer the same product re-branded and with tiny firmware variations), has issued a recall of this model due to a fault which affects a small number of drives.
I have had an OCZ Sandforce Vertex 2 drive for a year, which so far performs well with no issues, but I was aware of the problems as well as the slightly "weird" technology used so I didn't update my Intel SATA drivers to the latest version (v10) and stopped myself from buying the new drive version despite very impressive performance, opting for something "safer" i.e. more mainstream instead.
ISTR that most of these SSD controllers get a good deal of their grunt by implementing two drives internally with the data striped across them.
Oddly enough, the last time I saw this behaviour was when Abit shipped a BIOS version for the NF7 mobo, fucked up the bit for the on-board Silicon Image RAID controller and everyone using RAID went to data corruption and bluescreen hell.
"currently less than 1 per cent of all our customers are affected. "
Take (number of consumers reporting a fault)/(total number of customers for all OCZ drives)*100
By this standard should 1 in 10 747's immediately drop out of the sky, Boeing could reasonably state "less than 0.000000000001%* of our customers have been affected. Although none have contacted us in person. So maybe it's not that bad."
*please don't ask to see my working
Many users believe this issue is the same for Corsair 3 series drives (which are based on the same Sandforce 22xx controllers), though OCZ has denied it. Corsair 3 series drives hit the same problem, across multiple OSes, as soon as they started shipping; notably, they started shipping around the same time the 2.06 firmware update appeared for the OCZ drives, and it seems to be always people who've updated to 2.06 who get the problem with OCZ drives. So the general belief is there's something bad in that firmware update, and the Corsair drives shipped with an equivalent firmware to the OCZ 2.06 firmware.
I bought one of the affected Corsair drives and replaced it with a Crucial as I couldn't wait for a fix, but Corsair's response seems a lot better than OCZ's. Their forum thread did a lot less 'blaming the user', and when they were able to reproduce the issue, they took it to Sandforce, and shortly after, issued a full recall for the affected drives (they reckon only the 120GB model is affected), saying that both hardware and firmware issues were somehow involved, and bearing the full cost of exchanging the drives (including shipping).
This seems rather better than OCZ's response. Although really, neither company should have let such a huge flaw through testing.
I am in the middle of RMA'ing a Vertex2 60GB. Sometimes it is seen in BIOS, other times not. This drive probably has 100 hours on it of light use.
Its a known issue like the V3 referenced in the issue. Fortunately, the last several months I've been busy on my work laptop to not even turn the hex-core the V2 is in, on. So missed the last OCZ crisis and outright malfeasence on the V2 34-25nm fiasco.
But, it did give me pause to think about doing business with them. And Corsair's definately looking like they are a class act.
Once I get this V2 RMA successfully completed, I'm getting away from anything Sandforce for my next SSD, that will be coming as soon as I can sell this one.
Intel, Marvell, Samsung, heck even JMicron.
But never again, OCZ.
I've had the opportunity to play with plenty of SSDs over the last couple years, and I can tell you that Sandforce controllers (while not my favorite) aren't always bad. There's quite a lot to be said for the firmware, which is totally up to the drive manufacturer. It seems to me that the consumer drives, tuned to score highest in benchmarks and boot Windows fastest, are always somewhat less reliable than the enterprise ones (shocking, I know.)
In any case, the Sandforce enterprise controllers (1500, 2500 series) aren't half bad, especially when capacitor-backed.
That said, I do prefer the Intel G3 over anything - even without considering that it's by far the cheapest capacitor protected SSD available, the price to performance / capacity is pretty sweet. And I know that the G3 is somewhat higher quality than your average consumer Sandforce or Indilinx drive.
I wish the Vertex 3 failure was a bluescreen for me.
Mine just "dissapeared".
Not recognised in BIOS, not powering up / being recongnised in a USB caddy.
Just plain *gone*
And that was with the latest firmware.
Bought last Friday, dead this Tuesday.
Never going to buy an OCZ product ever again - I should learn - their RAM is generally crap too.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
