X64

I have recently got 4 x64 ssd drives and have put them in a raid 0 setup, everything is running fine and the speed is great. I ran Crystal Disk Info and it appears that I have 4 drives with FW version 2.0 that support Trim. I know Trim does not work with raid. Is CDI showing a correct reading through my raid that its FW version 2.0 and supports Trim? So if in the future if I use them as single drives they support Trim.

I have one other concern. When I click through the disk health reading, on 1 drive it is 98% the other 3 are at 100%. Is this anything to be worried about? What would be the reason for that?

If you have 2.0 then you have drives that will use T|RIM in a single config. That revision also has improved Garbage Collection which will help keep up performance while running them in RAID.

As for SMA|RT info related % health scores, Ignore them IMO. SMART on SSD's leaves a lot tpo be desired. The only ones to get SMART reporting useful info IME is Intel. Both Indilinx and Samsung drives often state nonsense values. I installed a brand new X64 in a customers machine three days ago and the health level stated |"Warning" and write cycle count was at ~ 50,000, clearly nonsense. The drive had not been used and works fine.

Hmm I have an X64 with firmware 0.1 and crystal diskinfo say it supports trim, is this realy true?

Nm I saw the answer in another thread.

Psycho101, what's with the random | marks?

I have a KB with very shallow keys and sometimes hit that key by mistake. Feel free to edit them out if you wish, hopefully it doesn't detract from the meaning of my posts. As long as the erroneous punctuation is the only complaint then I think I'm doing pretty well. :biggrin:

To any gamer considering getting a Razor Arctosa: they're awesome for gaming, very responsive, but are extremely poor for typing, especially for touch typists as the "Feel" of the thing is a little off-putting.

If you have 2.0 then you have drives that will use T|RIM in a single config. That revision also has improved Garbage Collection which will help keep up performance while running them in RAID.

 

As for SMA|RT info related % health scores, Ignore them IMO. SMART on SSD's leaves a lot tpo be desired. The only ones to get SMART reporting useful info IME is Intel. Both Indilinx and Samsung drives often state nonsense values. I installed a brand new X64 in a customers machine three days ago and the health level stated |"Warning" and write cycle count was at ~ 50,000, clearly nonsense. The drive had not been used and works fine.

Does Garbage collection work with the x64 in Raid 0?

In this thread it appears it does not.

http://forum.corsair.com/v3/showthread.php?t=83325&highlight=garbage+collection

Does Garbage collection work with the x64 in Raid 0?

In this thread it appears it does not.

 

http://forum.corsair.com/v3/showthread.php?t=83325&highlight=garbage+collection

According to the FAQ there is no Garbage collection in the x series: http://forum.corsair.com/v3/showthread.php?t=81189

Also, the x series is now shipping with newer firmware than stated in the FAQ that does support TRIM.

On the contrary, the whole point of beefing up Garbage Collection is that it works with both OS's that don't support TRIM and with RAID configs in all OS's regardless of TRIM support.

Having SSD's in RAID or not does not effect the running of any kind of GC in any way. GC is an entirely self contained process within the SSD's unlike TRIM which requires communication between SSD and OS via chipset and drivers.

You also already confirmed in a post you replied to written by me that GC would function in RAID. It took a while but |I did get an answer.

No offence but please check this carefully before posting because if this coming FW update doesn't support GC that functions when using disks in RAID and with non-TRIM OS's then prepare for a HUGE backlash from many angry people. A certain 3 letter competitor has had a GC FW that works in RAID and on Vista/XP for many months and Indilinx's last couple of builds that contain a combined TRIM and GC FW (I assume your update is based on this) also functions fine in RAID (the GC portion only OFC).

Bumping this for an answer as it's an important issue. If Corsair have not implemented GC in such a way that it functions regardless of the drives config (the ONLY way GC can be set up really) then it's pretty pointless releasing the FW, let alone getting the updater stable.

To confirm, RAM Guy definitely agreed with me in a previous thread that Corsair were implementing TRIM for Win 7 and GC for XP, Vista and RAID configs in the same FW update. The Indilinx FW's that the update is no doubt based on handles GC in non TRIM and RAID configs just fine on another brand of SSD I own (Rhymes with "Bun hore") and that's just an untweaked Indilinx build, not even a very recent one to be honest.

I would appreciate if you would check, thanks.

As I say, note that Garbage Collection is an internal process and does not require any interaction with the OS, rather it's just between the SSD Controller and its NAND. Also note that the GC talked about is merely an updated algorithm to the GC that is present in all Indilinx drives anyway and is a vital part of the wear levelling algorithm. Wear levelling and regular GC work fine in RAID or in a non TRIM OS, so the beefed up GC should too as it's a direct replacement and merely more agressively tuned to pre erase free space sooner. Every other manufacturer's Indilinx beefed up GC has worked great in RAID and in Vista for me, I've tried ~3-4 different manufacturers with maybe 3 FW revisions (all direct from Indilinx not customised)

Ok, thanks, I appreciate your efforts.

If it turns out that the forthcoming X series update does not have the propper souped up Garbage Collection, would it be possible for you to suggest one be implemented when the updater tool is complete? I'm sure many people will be needing this type of FW as there must be more people running Vista or even XP than Windows 7 and quite a few performance freaks who run RAID arrays of X series drives.

It is definitely possible to implement an effective GC for RAID and non TRIM OS's either in conjunction with TRIM on the same FW or even seperately with no TRIM. A certain competitor offers two FW's a 1.4 and 1.41, 1.41 being GC only with TRIM disabled for use in RAID and Vista/XP. Indilinx's own generic FW version (the last 3 actually) also support RIM and GC perfectly. There will be a lot of disappointed loyal customers if Corsair does not correctly implement the agressive GC algorithm.

It really does make a difference. On the RAID array I tested, transfers were degraded at ~110MB/s write (two 32GB drives, not corsair branded, Indilinx latest generic FW). After I ran IOMeter across the whole drive (created ~38GB worth of test files then deleted them), the GC had completely pre-erased all the blocks that were used then deleted, without need for TRIM or being dependant on chipset drivers etc. Speeds picked up to ~185MB/s write over the course of the day (GC must wait till the machine has been idle for a bit, which would explain the delay before full performance).

Here is my latest Atto test. I would say the numbers look pretty good.

http://i307.photobucket.com/albums/nn281/ed6698/ssdatto6.png

Your small transfers are extremely poor. What chipset are you running the drives on? If it's an Intel chipset, download Intel Matrix Storage Manager, install the driver and config utility and then activate the Write Back cache. I'm getting 0.5k read and write figures of 50MB/s + with 2 drives compared to your 3-10MB/s. The cache will help all transfers, especially those in the 0.5-64k range.

A: I would suggest using Diskeeper Professional on any Raid array as it will help maintain performance with little or no intervention.

I do use Diskeeper, infact I mentioned its usefulness a month or so ago, spawning a couple of threads on the subject. However, Diskeeper will do nothing for a drive that has severely degraded or been abused using IOMeter. In the situation I described using IOMeter to fill and then purge the drive, Diskeeper unfortunately doesn't stand much of a chance restoring performance. It is however good to run on a RAID array that sees light to moderate usage, like mine does.

I would suggest the Raid be set to 128K and set the Quick format allocation to 32K for best performance. You can use 4095 for the format allocation but our tests showed 32k Gave best over all performance.

I have my OS on my raid, so I don't think I can do a quick format like that. I am already using a 128k stripe. By the way I am not having a issue. I was posting some ATTO numbers and just responding to someone saying I am getting poor performace on small file tranfers. Take a look at my numbers and see what you think, it is a couple posts up.

Now that I found this I have learned how to 32k format allocation with the OS on the raid.

http://forum.corsair.com/v3/showpost.php?p=428886&postcount=2