PC Hardware → Re: TRIM / "garbage collection" with RAID0

Thanks for educating me, Octavean .

I didn't realise the chipset series was so important. In fact, I'm not quite sure why it would be -- think about what actually drives the RAID bits of the chipset when it's in RAID mode: the option ROM (think: "RAID BIOS") is what handles it. That's quite simply just a bunch of x86 code.

It sounds to me like Intel doesn't want to deal with implementing the necessary option ROM bits on older chipsets. They would have to go to every motherboard vendor and tell them to update their system BIOSes (which is what contain the option ROM code for RAID as well as the option ROM code for AHCI), etc. etc... I'm willing to bet that starting with the 7-series chipsets, from the get-go, the option ROMs they started with (thus distributed to all manufacturers) contained the necessary code for this to work (even though the driver didn't). I bet Intel wants to "start with a clean slate". Or it could be that Intel just wants people to buy new crap. Or both. Sigh.

Basically what I'm saying is that there isn't anything silicon-level that would inhibit this from being done on 6-series chipsets or earlier. *grumbles* And without a SATA-capable ATA protocol analyser, there's no actual way to tell if their "7-series and newer only" claim is even legitimate.

Not that I have answers for the OP, but what is engineering possible doesn't always equate to sales koitsu .

Lovely world we are in and all that hype.

From that though, on board raid is not a dedicated raid card - would that make any difference for the OP if he/she was specifically looking for TRIM?

Unlikely since a RAID card would not have TRIM support in a RAID 0 configuration regardless of the chipset whereas select Intel 7 series chipsets do.

Well thanks for your most informative links and replies Octavean.

Looks like I have opened a can of worms here regarding RAID0 and TRIM.

At the time of my RAID creation and Windows installation, I was led to believe RAID0 and TRIM together was possible, and had NO inherent problems!

Can you further enlighten me with what kind of "issues" I can expect to encounter with my present Win7 installation on to (2) 64GB Crucial M4 SSDs in a RAID0 array?

Thanks again

Unfortunately I am not entirely sure what you might encounter over time.

I have a number of different SSD models of which a Crucial M4 256GB SSD is one of them. However, I don’t currently have an SSD RAID 0 array setup. Although I have run such configurations in the past and have had no real problems or major concerns over performance loss:

»SSD Raid 0 Array 4x60GB Setup Test Run

quote:

---

Author: Allyn Malventano
Date: February 17, 2010
Subject: Storage
Manufacturer: Kingston

TRIM

I don't have and pretty charts or graphs to explain this next part, but I will share an observation I made during my fragmentation testing. When running my fragmentation tool, I observe IOPS drop as the drive becomes more and more overloaded with the task of tracking the random writes taking place. Here the JMicron controller behaved like all other drives, but where it differed is what happened after the test was stopped. While most other drives will stick at the lower IOPS value until either sequentially written, TRIMmed, or Secure Erased, the JMicron controller would take the soonest available idle time to quickly and aggressively perform internal garbage collection. I could stop my tool, give the drive a minute or so to catch its breath. Upon restarting the tool, this drive would start right back up at it's pre-fragmented IOPS value.

Because of this super-fast IOPS restoring action, and along with the negligible drop in sequential transfer speeds from a 'clean' to 'dirty' drive, it was impossible to evaluate if this drive properly implemented ATA TRIM. Don't take this as a bad thing, as any drive that can bring itself back to full speed without TRIM is fine by me, even if that 'full speed performance' is not the greatest.

This type of self-healing (i.e. without needing TRIM) is great for those wanting to run a few SSD's behind a RAID, since no RAID implementation is currently capable of passing TRIM from the OS to the arrayed SSD's. Better yet, considering this drive is tailored to the budget crowd who may very well still be running XP or Vista, it's good to have a few choices that don't require TRIM to maintain decent levels or performance.

---

»www.pcper.com/reviews/St ··· rance/Fr

This was applicable for the SSD model that I was chiefly using in the RAID 0 array which was the Kingston SSDNow V Series SNV-S2 64GB (3x but not applicable to the single 60GB OCZ Agility in the array).

Personally I would just keep an eye on performance overall. That does not mean benchmark the configuration aggressively. It just means take note via empirical observation of your system in everyday use and maybe one or two benchmarks a month (or every other month) to look for a delta. Some SSD models (controllers) may degrade performance somewhat as the storage is fills up (independent of TRIM and Garbage Collection concerns) so keep that into consideration as you record your data.

As SSD prices fall you may find that you can replace your 2x64GB RAID 0 array relatively cheaply. I replaced my 4x60GB RAID 0 configuration with a single 240GB SSD that was about the price of one of the single 60GB / 64GB SSD models when they were new.

I’ve personally been thinking about replacing my Asus P8P67 Pro with a Gigabyte GA-Z77X-UP5 TH (dual Thunderbolt) for ~$239.99 or a GA-Z77X-UP4 TH (dual Thunderbolt) $184.99.

Thanks.

What Octavean said is generally correct -- as of this writing I don't know of any hardware RAID controllers that provide TRIM.

All the manufacturers of HBAs (ex. Highpoint, Areca, 3Ware, LSI) say the same thing: we acknowledge the importance of TRIM in a RAID configuration, but driver-wise everything is implemented via SCSI emulation and TRIM is purely part of ATA protocol, thus getting it to work is somewhat tricky.

Solving the problem at the firmware level, or even silicon-level, is ideal -- it just requires that everything be designed a very specific way (from the ground up). It involves tracking LBAs to some degree. (See, this is where I wish I worked at Intel -- I would love to know what all the engineers had to do to get this to work on their recent chipsets + RST. )

RST:

So would this also be a reason to obtain Intel SSD's too?

Or does it work across differing manufacturer platforms, as long as the chipset is Intel on the motherboard and the SSD isn't too overly relative to the raid?

As long as the SSD(s) supports TRIM and all the other requisites are satisfied then there should be no problems. The SSD(s) does not have to be of Intel manufacture.