ocz agility 4 write freezes linux

[mercnz]

well i've been having issues with ocz agility 4, it stopped writing properly in linux, did a firmware flash from 1.5 to 1.5.2 and it came right, made a backup of all of my data, then used it for a few months, then it stopped writing again. no new firmware to try flashing, so i tried rma to point of purchase, who then come back with no fault found.

they stuck windows on it, and apparently it had worked fine, and now they want to charge me for no fault found, and i still don't have a ssd that i can trust.

my guess it'd be something like a firmware issue / garbage collection issue, but am i stuck if it works in windows? it was also going slow, with 180mb/sec in linux when it's meant to do up to 420mb/sec. it was under provisioned, and that was with hdparm. with dd writing a file it was ~270mb/sec, but i mostly tested because i was finding it slow.

i replaced it with a samsung 840, which has been much smoother, without pauses/delays. i'd also tried the hard-disk in another motherboard, i7-3770/z77 versus i5-2500k/p67 and it was behaving identically. but i managed to copy my data off on the i7 to another hard-disk.

i'm getting a bit skeptical of ssd's when they can have weird issues like this. this is the 4th ssd issue i've seen. there was a crucial m4 that had uptime bug, and would die after an hour being on, another crucial that was like under 1mb/sec without nobarrier and some other tweak, an agility 3 that would bsod, an agility 4 that somehow gets into some kind of write freeze.

googling i can't find anyone else with similar issues, but i'm finding it hard to even find anyone using one with linux? swapping to the 840 (non-pro) i've had no problems and better performance. but now i'm stuck with some fee, and having to try and onsell the ssd, and i'm wondering if i really have no recourse.

 

[drescherjm]

but i'm finding it hard to even find anyone using one with linux?

I have had no problems at all on Crucial M4s or Intel SSDs on linux. My recommendation is to stay far away from OCZ. Especially their low end models. Also I would avoid all drives less than 120GB at this time.

crucial m4 that had uptime bug, and would die after an hour being on

That was fixed quite some time ago with a firmware update.

it was also going slow, with 180mb/sec in linux when it's meant to do up to 420mb/sec

How did you measure that?

 

[CPL0]

Hi mercnz, welcome to the forum.

I have a vertex 4 which is part of a RAID0 array that did something similar to that while using Windows, each time something was attempted to be written to the disk it would presumably go into panic mode as the disk would disappear from the system. Reading only was fine. The only way to see the disk again was to remove the power and reconnect which would restore read only, as soon as a write occurred the disk disappeared again.

A secure erase fixed it, firmware is still at 1.5 and IIRC you should have the option to reflash the same version although I have never flashed the vertex 4's.

It's only happened once so far, (I know, once is one time too many) not sure what to suggest really.

 

[mercnz]

I have had no problems at all on Crucial M4s or Intel SSDs on linux. My recommendation is to stay far away from OCZ. Especially their low end models. Also I would avoid all drives less than 120GB at this time.


That was fixed quite some time ago with a firmware update.



How did you measure that?

yeah, i am staying away from ocz now. i think i was kind of foolish. i had ocz agility 3 with stability issues attributed to sandforce. got an agility 4 that had whole new controller and sounded like it wouldn't have the agility 3 problems, then find out that it goes into low performance mode when using too much disk-space.

the agility 4 is 128gb i think? or 120gb. i have samsung 840 non-pro 120gb, and 250gb. even the 120gb 840 non-pro is faster than the agility 4.

the agility 4 that failed was partitioned down to 60gb, the agility 4 that i'm using windows on is at 90gb.

the uptime bug was pretty easy to fix, it's more a wtf than anything, and was just using it as a cache on another system, so it failed nicely.

measured disk peformance with hdparm and dd.

 

[mercnz]

Hi mercnz, welcome to the forum.

was surprised i didn't haev account. i've read the forum quite a lot

I have a vertex 4 which is part of a RAID0 array that did something similar to that while using Windows, each time something was attempted to be written to the disk it would presumably go into panic mode as the disk would disappear from the system. Reading only was fine. The only way to see the disk again was to remove the power and reconnect which would restore read only, as soon as a write occurred the disk disappeared again.

A secure erase fixed it, firmware is still at 1.5 and IIRC you should have the option to reflash the same version although I have never flashed the vertex 4's.

It's only happened once so far, (I know, once is one time too many) not sure what to suggest really.

well uhh, at least i'm not alone. how could you tell that it disappeared from system, were you using as secondary drives? i'm a bit dubious of raid0. i didn't realise could firmware flash the same version over top again. but it's a real pita when you have OS drive that dies. i have a raw disk backup of the whole disk, but even if i did that every day, it'd still be annoying ..

 

[CPL0]

Well when it happened the system became unresponsive, you don't appear to loose the disk straight away because Windows has cached quite a bit of stuff from it, it's a little while before it's really noticeable. When rebooting the Intel OROM posts showing one of the array disks missing, from there try the power cycle trick, the array is back and can read okay, soon as a write to the array occurs, bang!.

Split the array, test the offending disk on it's own, confirm the problem happens on write, read is okay so back up the data on it so only have to restore one disk. Using the offending disk on a esata of another PC try SE, check again if it can be written too, okay this time, restore backup to that disk and join the array back up. PITA is correct.