Losergamer04 wrote:I personally vote for software raids using the OS. It removes a potential harware failiure point. A good backup of your OS is all you need to restore (which you are doing, right?). Also, the cheap cards and onboard stuff typically put off the calculations to the CPU anyways, so they are moot if you want high-performance raid.
Yes, the RAID implemented on chipsets and cheap add-in cards essentially is software RAID, just implemented at the driver and firmware level rather than in the OS. So you can boot from it, but it doesn't have any of the throughput and system utilization advantages offered by real hardware RAID (one that uses its own processor and memory).
You should also ensure whatever drive you buy has built in Garbage Collection, too.
They all do, at this point (AFAIK). But the characteristics (aggressiveness and effectiveness) vary from one controller to another.
Losergamer04 wrote:When you delete a file, it just removes the location of the data from the file table. TRIM will zero the sectors, preventing the read-write hit on a MLC drive. Look at every TR SSD review to see what I'm talking about. They do a special section on TRIM performence.
This isn't precisely correct. TRIM doesn't necessarily cause the sectors to be erased, at least not (necessarily) immediately. What it does do is inform the controller that those sectors (technically, the NAND blocks that make up those "sectors") are no longer in use, allowing the Garbage Collection algorithm in the controller to pick them up as it does its job. If the drive is very low on space, they'll get erased and reused pretty quickly, but if there's adequate free space on the drive they may be sitting around for an indefinite amount of time. (The flash NAND used in SSDs has to be erased before it can be rewritten, but that's a slow extra step which is why a heavily utilized drive may see its write speed drop; to combat this, the GC tries to go keep an adequate supply of zero'd blocks available by scavenging them when the drive is idle, but if there's plenty of free space it may not do so right away. Complicating this is the fact that the block size for erases is larger than it is for writes, and files never fit cleanly into blocks anyway, so the GC has to shuffle things around to try to pack them efficiently -- while also keeping track of the wear on each block and trying to balance that so all of them have been erased/written roughly evenly).
I belabor this because I see a fair amount of confusion about GC vs Trim (they aren't replacements for each other: Trim is an enhancement that allows the GC to be more effective) and I also wouldn't want anyone reading this to just assume having TRIM enabled on a consumer SSD meant that any sensitive information would necessarily be getting zero'd out immediately on file deletion when in fact it might be sitting around hidden from user-level tools but still available for anyone with the bare minimum of forensic utilities.