Hellhammer: I can't comment on the Plextor products but you can be right in this case. I believe Plextor had always had custom firmware enhancements? But either way, the Vertex 4 is an unfinished product with throttling firmware. The M500 will run on the same controllerchip but with different firmware which will make it a better product. The quality of the firmware is extremely important. OCZ itself commented on the fact that 9 out of 10 returned SSDs were failed due to software issues, while only 10% failed due to hardware issues like defective NAND.
Warning: rant about OCZ ahead!
OCZ improving on its reliability is not a big challenge - some of their products have had
up to 40% failure rate according to some sources. Generally, I dislike OCZ alot. They have done their customers such a disservice. They operate in the enthusiast-market. Enthusiast are customers who have an admiration for technological advances but lack sufficient technical know-how. These kind of people do overclocking and generally are the first to try out new stuff, the kind of users that put lights in their casings and generally spend a lot of money on things the ordinary computer-user would never spend. These Enthusiast-customers wanted a REALLY COOL ssd, but what they got from OCZ instead is nothing but lies and disappointment. Lies because virtually all specifications are misleading and meant to misinform their customers. OCZ has sold their 75MB/s SSDs as 500MB/s for years, ever since the Vertex 2 with Sandforce. Even now when they migrate to Marvell controller they use write throttling causing them to give higher specifications than customers would encounter if they use more than half of their SSD. Virtually all users want to use more than half the capacity on their SSD, so what OCZ puts on the box doesn't represent actual usage.
Even worse, OCZ had a past of almost criminal behaviour. They sold memory to enthusiasts which want to overclock and generally wanted quality memory. But what they got was simple OEM memory that OCZ bought and overclocked it by reprogramming the SPD and selling them off as more expensive memory running at higher frequency. But this also was accompanied by higher voltages (i.e. from 1.5V to 1.65V). Customers could have just as easily bought the cheaper OEM memory and overclock it themselves. A nice analogy is what is happening in Europe lately: cheaper horsemeat is being sold as more expensive pork and beef. I consider this light criminal behaviour.
Then there is the issue of 25nm SSDs. OCZ was one of the first to profit from the migration from 34nm NAND to 25nm. Basically, the Vertex 2 users with 25nm NAND were screwed. They bought a 60GB drive but got 55GB, they got only 35MB/s of incompressible write performance instead of the normal 70MB/s because of half the channels were utilised due to using larger and cheaper 64Gbit NAND memory. In other words: OCZ sold you cheaper stuff and took the difference in price from the customer. The customer is always the loser when it comes to OCZ.
OCZ themselves know that they can hide behind the obscurity of technical nerdtalk which none of their customers understand. That is why they said their SSDs had "an incorrect IDEMA capacity" when referring to their 60GB SSDs having only 55GB of usable storage space. They simply use obscuring technical language to hide the fact they tried to rip off their very own customers.
Now I have done enough OCZ bashing for today. I must say it certainly feels good. I have done little less than explaining misleading SSD specifications to people. In general it just pays off to lie to your customers. It is so easy to sell a lie, and it doesn't matter people like me know better because I can only affect a small percentage of potential customers.
That said, even with high RMA rates like 5 - 40% this means a vast majority of OCZ users have no problems with their product. But you should expect nothing less from such an expensive product! The very least it can do is actually DO SOMETHING. Why else would you pay big bucks for a small drive, huh?
Of course, I respect everyones opinion. I have seen enough however, and will never recommend OCZ to anyone. They are the hedgefunds of the IT-industry and it would be a service to us customers if the company simply disappeared. Perhaps my dream will become reality:
http://www.streetauthority.com/inve...tech-stock-cant-afford-any-more-losses-459898. But somehow, the cockroaches always find a way to survive, hiding behind the next rock that is still wet underneath.
In the case of pure software RAID, I agree. If you're using "firmware" RAID, however, it's more complicated. I have to admit I don't know too much about how the firmware RAID really works but there's definitely some difference to normal ACHI mode as TRIM is not passed, which means LBA mapping is done somewhat differently.
Well, I can tell you a lot about how it works. Not much accurate information is known by the public on 'onboard RAID'.
Onboard RAID, Fake RAID, Driver RAID, firmware RAID, Hybrid RAID ... they all mean the same thing. It is NOT the same as software RAID, but extremely close.
Despire there being a lot of misinformation about it, it is actually quite simple: onboard RAID is simply a normal SATA controller paired with Windows-only drivers that implement RAID. All work is done by Windows drivers, the hardware is nothing more than a regular SATA controller that is unaware of any RAID functionality.
Difference between software RAID and onboard RAID
Well actually, there is one difference: the controller has an option ROM with firmware just like hardware RAID has. This allows bootstrapping, which otherwise is impossible for software RAID. So Windows can not boot from a software RAID5 because they have simple boot code. To overcome this limitation the option ROM contains firmware that allows users to create and delete RAID arrays in its own 'RAID BIOS'. This RAID BIOS will write 512-byte to the last sector of each drive used in a RAID-array. During boot stage, the option ROM firmware reads this information and it knows that the user created a 2-disk RAID0 for example. It then registers this virtual RAID device to the system BIOS using interrupt 19 capture. The BIOS can do basic reads from this virtual RAID array which allows booting Windows.
During the boot-phase of Windows, once the RAID driver is loaded it becomes active and will takeover the I/O path from the BIOS. From this point forward, all I/O will be done through the RAID driver and not the BIOS. In other words: once this part of the boot-phase is complete, onboard RAID becomes 100% software RAID provided by drivers alone. If during this phase the handover fails, you get STOP 0x07D blue screen which is extremely common. This means the RAID drivers failed to attach and Windows can not boot.
The important clue here is that
onboard RAID does not gain any hardware acceleration from the controller, as many people believe. In fact, you could use Intel's RAID drivers on an AMD controller or vice versa. The driver of course prohibits this, but this is an artificial limitation. In fact, there were bugs in Silicon Image FakeRAID drivers causing it to attach to other generic AHCI controllers like Intel or AMD. The drivers also hides the physical disks, otherwise you would see the RAID but also the individual disks which could be problematic.
Now, if you boot into Linux or BSD, you will see the TRUE hardware. You will see multiple disks instead of one RAID array. The Windows-only drivers only work on Windows platforms; so onboard RAID on non-Windows is nothing different than a normal SATA controller. On Linux/BSD you see the REAL hardware.
However..... to make things more interesting, Linux and BSD have their own software RAID. And they have written it so that they can read the last sector of each disk containing RAID configuration for virtually all kinds of RAIDs. Software/onboard/hardware RAID always use the last sector on each disk to store RAID metadata like stripesize, disk order, RAID level, offset, etc. So what they do is read this information and apply their own software RAID engine to mimic the way this onboard RAID would be handled under Windows.
As a result, virtually all onboard RAID is detected in Linux/BSD just fine. You can boot Ubuntu and it recognises your Intel or AMD RAID array just fine. Not only the virtual RAID array, but also the physical disks which are intentionally hidden on the Windows platform. Many people think this works because of acceleration of their 'RAID controller' on the motherboard. Haha!
😀
Even more funny, if you buy a OCZ Revodrive 1 or 2, you are buying a FakeRAID controller. This uses Silicon Image fakeRAID drivers under windows. But under Linux and BSD this controller is nothing more than a SATA controller with 2 or 4 SSDs attached to it. Yes, you can actually see four 60GB SSDs on a 240GB Revodrive! Version 3 of Revodrive is different because it uses more proper LSI SAS controller.
TRIM and FakeRAID
There is no reason TRIM would not work. If TRIM does not work, it is always the fault of software design not about hardware abilities. For example, owners of OCZ Revodrive 1, 2 and 3 will NOT have TRIM support in Windows 7. However, if you boot into Linux or BSD you WILL have TRIM support because the actual problem lies in the Windows-only drivers that prevents the use of TRIM.
Today, both AMD and Intel updated their RAID drivers so that TRIM in simple RAID0 arrays should work. But there is no limitation to this; RAID5 + TRIM is also possible and works just fine on non-Windows OS. FreeBSD allows RAID-Z2 + TRIM for example, comparable to RAID6.
The limitation in Windows lies in the fact that Windows implements TRIM only on ATA controllers, while RAID drivers hook up as SCSI device. This is an old-fashioned way of doing things. There is no
real RAID support; the RAID drivers simply emulate a SCSI harddrive. This always appeared to work just fine, but now we can see the disadvantages of this design with limiting TRIM, SMART, APM support. I do not know about Windows 8, but it is possible they implemented UNMAP for SCSI - which is equivalent to TRIM on ATA.
