Duckie and parsec - thanks for the response!! Duckie - My confusion, in large part, comes from lack of experience, however, if you go to downloads ( http://http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=20023&ProdId=3284&lang=eng&OSVersion=Windows%207%2C%2064-bit*&DownloadType=Drivers) for RST drivers for my board and read the DETAILED DESCRIPTION - WHICH FILE TO CHOOSE it states choose driver AND one of the F6 driver diskettes. My understanding now, based on your response, is that I do not need to download the F6 diskette - the driver alone is sufficient.
Hi can someone clarify the above please?
I too have just installed windows 7 (64-bit) on an ssd 320 series (80gb), and would like to install the intel drivers (rather than the native windows ahci). I am not running raid.
Is there a way to install the intel driver without using the f6 method during windows install?? Can I just install a file from within windows? If so which file?
I'd just like to confirm what Duckie said, from my personal experience. I've done exactly what he said, install the Intel RST driver after an OS installation, to use with my SSDs in AHCI mode. Simply download and install, I've done this on four PCs with Intel SSDs, and it's always worked perfectly. The RST driver is appropriate for Intel chipsets (not CPUs) from the 3 series through the 6 series, and several of the 900 series chipsets, and Windows versions from XP through Windows 7, 32 or 64 bit. The download page explains the few restrictions, which can be found here:
Some Intel chipsets do not support RAID, but this is not a concern if you plan on using the driver in AHCI mode. I have installed it on a non-RAID support chipset, the ICH10 (ICH10R supports RAID) successfully, but I am not sure if the installation program will complete with all of the Intel non-RAID support chipsets. I would think it will install fine but you never know with software.
The only small caveat is occasionally what is called the Option ROM on a mother board will not support the latest RST driver. That is why the instructions on the Intel download page suggests checking the download page for your mother board and use the Intel RAID driver found there. I have used Intel RST drivers that were newer than those listed on my mother board manufacture's download page without any problems. That may be because I did not use the driver in RAID mode, just AHCI mode. All in one PC's (HP, Dell, etc) may be more sensitive to this issue than personally built PC's, so use at your own risk. BIOS updates may also update the Option ROM, so flash your mother board to the latest BIOS if you have driver issues. Also, do not worry if you must use an older version of the RST driver, the newer version is not necessarily better, and the updates to it are likely due to simply adding support for new chipsets.
This thread has been usefull for the most part. However, I still have some confusion regarding TRIM support in RAID 0. I have 2x80 GB Intel X-25M G2 SSDs in RAID 0 on a P55-GD65 mobo.I am not using a RAID card, and my OS is Windows 7 Ultimate x64. I just flashed the latest firmware update for the drives. According to the SSD Toolbox, TRIM is not enabled. From reading this thread, I want to see if I understand this correctly. If I back up my data, set the drives to ACHI rather then RAID, rebuild the area, and restore my back up, the drive will support TRIM. Is that correct? If not is there any way to manually run TRIM from time to time? Assuming Ubuntu, or any other flavor of Linux support TRIM, could I change my RAID setting in the BIOS, boot in to Ubuntu or other flavor, and get a trim done this way, or would it be useless since the drives would no longer be in a RAID stripe?
Also I was bot confused in regards to the driver references. I have the latest drivers from the Intel site here, rather then the drivers from the MSI site. Which drivers are preferable?
Thanks in advance for any advice, and thanks for the nice sticky of info. Disabling superfetch alone has already sped up my drives, but I ran an analysis only of the drives using Smart Defrag, and the out come was not pretty...Just to be clear I never proceeded with ac actual defrag.
The RAID - TRIM thing is actually pretty simple. As long as a SSD is part of any RAID array, the type (0, 1, 5, etc) doesn't matter, the TRIM command will not be passed to the SSD by the RAID driver. More accurately, the TRIM command will not be acted upon by the RAID driver, and will never get to the SSD. It makes no difference what type of RAID implementation is used, RAID software and a chipset or a RAID card, if a SSD is part of a RAID array, TRIM will not work with it.
That last part is the subtle point, the OS will have TRIM enabled and may try to pass a TRIM command to the SSD (more on this in a moment) but that command will not reach an SSD that is part of a RAID array. The reason for this is clear if you think about it.
A single, non-RAID drive is controlled by the file system of the OS. Drives in a RAID array are controlled by the RAID driver and the SATA interface chipset, or a separate RAID card and it's software. The OS is not aware of the way files are stored in a RAID array, which is different than the OS file systems view and normal storage of those files. The RAID driver provides files and file operations to the OS in the form that the OS is familiar with, although the actual layout of and operations on files in a RAID array are different. The RAID driver provides this necessary translation.
So when the OS sends a TRIM command to tell the SSD's controller that certain blocks are no longer in use and may be made available, the block addresses do not match what is stored in the RAID array. Apparently, the information in the TRIM command is not sufficient for the RAID driver to complete a translation, which also is likely not even applicable to the manner in which files are stored in the RAID array. The result is the TRIM command cannot be applied to drives in the RAID array, so it is discarded. One obvious theoretical fix for this would be making the RAID driver capable of sending TRIM commands to the drives it controls, but we don't have that yet.
Once a drive is removed from a RAID array, the OS is controlling it directly again, and TRIM commands can be executed successfully on it. The state of that drive after removal from the array, and the OS's knowledge of it's contents may not correspond perfectly to allow it to be TRIMed optimally. Which is why the best way to perform maintenance on a SSD in a RAID array is to back up the array, remove the drive from the array, secure erase it, and rebuild and restore the RAID array and data. You can also run the Intel SSD Toolbox Optimizer on Intel SSDs that are not part of a RAID array.
I don't completely understand this statement:
"If I back up my data, set the drives to ACHI rather then RAID, rebuild the area, and restore my back up, the drive will support TRIM. Is that correct?"
You lost me on the "rebuild the area, and restore my back up", is that drive in a RAID array or not? If a drive that was formerly in a RAID array is changed to a standard Windows NTFS file system disk, then TRIM will work with it. You can manually TRIM Intel SSDs with the SSD Toolbox Optimizer that are not part of a RAID array. When you said the Toolbox said TRIM was not enabled, that is because the SSDs were in a RAID array, not because TRIM was disabled in Windows, unless you specifically did that.
There is no trick or technique using a different OS that allows TRIM to run on a drive in a RAID array, for the reasons I explained above.
Parsec, thanks for the reply. You stated that if the a SSD is part of a RAID array, it will not receive the trim command period. Sorry but acording to the first post that is incorrect. Sorry if this sounds nitpicking, but you said "a SSD" rather then "the SSD" which would make me think you were referring to the X25M specifically.
As for using Ubuntu/Linux, yes, I can see where your coming from now. I think I was to tired to properly think that statement through before I posted it lol.
However, like you, I don't understand your statment:
"You lost me on the "rebuild the area, and restore my back up", is that drive in a RAID array or not? If a drive that was formerly in a RAID array is changed to a standard Windows NTFS file system disk, then TRIM will work with it."
Where exactly did I loose you? It is possible to run a RAID configuration in AHCI rather then RAID itslef, is it not? While AHCI itself is enabled when chooisng RAID, from reading comments above, I was under the impression if the RAID array was set to AHCI rather RAID, this would make the controller pass the TRIM command along. However, after reading the information again with my brain fully awake this time, I now see I missread the information provided.
Thanks for the response.
Xplorer, are you referring to this (by DuckieHo):
TRIM is supported by the RST driver in ACHI or RAID mode. The SSD just cannot be a member of an array. You can actually switch between AHCI and RAID mode fine since RAID drivers is a superset of Intel's AHCI driver.
This is a correct statement. Since you are using a RAID 0 array, that is what I was talking about. The model of SSD doesn't matter in general, but there were a few that did not support TRIM at all. Don't miss this part:
The SSD just cannot be a member of an array.
Or it is a single drive, as I called it, rather than a member of a RAID set. Changing the SATA mode with an existing RAID array from RAID mode to AHCI will cause the array to be destroyed, you can't have a functioning set of drives in any RAID array type in AHCI mode.
The point of his statement is that TRIM will be passed to drives that are not a member of a RAID array when the SATA mode is RAID. That occurs because the file system on the single drive is not being controlled by the RAID driver, so the format of a single drive is still in the native NTFS format.
If you have a RAID array operating correctly with the SATA mode set to AHCI, that is amazing.
Parsec, I never said the statment was incorect. I stated that I misread it.
As for your comment:
Changing the SATA mode with an existing RAID array from RAID mode to AHCI will cause the array to be destroyed, you can't have a functioning set of drives in any RAID array type in AHCI mode.
I am unsure if this is unique labeling to my BIOS but RIAD type ist listed in 2 places. One of which lists RAID and AHCI if memorey serves me right. The other lists IDE,RAID, and AHCI as the options. In the second set as best as I recall, any of the three options can be choosen and keep the RAID array in tact. I am using AHCI as we speak. Being an FAQ thread I just thought it best to clarify this for any one confused. I am not trying to be smart or anything, just stating facts for the sake of clarity. I suspect it is just a matter of being labeled differently in cetrain other BIOS. I do apreciate your response!
"I am unsure if this is unique labeling to my BIOS but RIAD type ist listed in 2 places. One of which lists RAID and AHCI if memorey serves me right. The other lists IDE,RAID, and AHCI as the options. In the second set as best as I recall, any of the three options can be choosen and keep the RAID array in tact. I am using AHCI as we speak. Being an FAQ thread I just thought it best to clarify this for any one confused."
You may be referring to the Marvell chipset's RAID capability in one case, and the Intel chipset's RAID in the other. I am not a supreme RAID expert, but given a set of drives in any RAID set, switching out of RAID mode does not keep the drives in a RAID array is the way it is AFAIK.
Someone else will need to either confirm or debunk my statement about this, I am prepared to be educated if that is the case!
parsec, would you please comment on IRST alpha driver 188.8.131.525 and trim support for RAID0
Edit: Looks like nobody knows so here is an update if anyone is interested.
quote from Intel RAID OROM 184.108.40.2061:
"If memory serves..." ?!? You're trying to solve a technical quandary, but haven't provided the BIOS manufacturer, the OEM if applicable, the BIOS version, etc. This would go a long way to assist other user's to look into the issue and figure out ways to help. Nevertheless, working with the information you did provide, selecting the options in the first set of items (RAID or AHCI) would seem to specify which mode (BTW, "architecture" may be a more descriptive way of thinkng of it, though it is not likely the manufacturer would say that as they have to use discrete meanings) you wish the computer's hardware layer to handle or treat the drives. If you had two drives, RAID is a valid option (incidentally, RAID would most likely work with just one drive, though pointless--at least I can do it with my BIOS), and would be necessary to implement a RAID setup. Otherwise, your would select AHCI--no array. The second set of options would, using a bit of assumption, is selecting the compatibility mode that the storage controller uses when addressing the drives. While it would be unlikely you would be able to select RAID compatibility addressing if you already selected AHCI mode, it is theoretically possible--the BIOS may be able to handle the complexities, but again, I doubt it. So if you selected RAID mode for the controller, then the logical selection for the drive addressing is RAID. If you selected AHCI mode for the controller, then the performance and advanced features of AHCI would be desirable, so you would select AHCI for drive addressing. So why is IDE an option? For compatibility. It is possible that your BIOS has extended capabilities, but short of that, being able to select the addressing mode allows older OS's to use a very modern drive--the BIOS will operate in AHCI, but to the OS it will appear as if the IDE drives it can handle are present. OS's are just one example. (BTW#2, IDE is remnant term for use in this context as both PATA ("IDE") and SATA drives have the electronics on the drive unit itself, as opposed to a more complicated system that was in use before the drives electronics became integrated, but I digress).
Now as to why I would think the first set would dictate the second set and not vice versa. If the second set was the mode (drive architecture), then selecting IDE would mean the drive addressing options would need more than AHCI and RAID. It would present the architecture as IDE, but the drives would be expecting AHCI addressing. This is why it is probably the way I described above.
I take responsibility for my post's accuracy, but with the caveat I am working with limited information. Perhaps next time you could shutdown and enter the BIOS to make sure of your "memory serves"--and while you're there, get the manufacturer, the version, etc. The details are helpful in deciphering this.