![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Which RAID card allow TRIM?
- Thread starter ben805
- Start date
Red Falcon
[H]ard DCOTM December 2023
- Joined
- May 7, 2007
- Messages
- 12,475
Actually, this can be done if the RAID controller is acting as a HBA and the SSD(s) are not running in RAID, i.e. individual drives.
That's incorrect but that's not what OP was asking. Even in JBOD mode the controller would require TRIM support in its vendor-supplied driver. Which means it's not the generic TRIM-enabled microsoft driver doing the talking to the drives.
The short answer to OP is "not currently", but I know for a fact several vendors have SSD optimization on high priority, including TRIM support, but its tricky since it means connecting layers that have traditionally been separate - i.e. a RAID controller's firmware and O/S driver don't normally know what's happening at the filesystem (partition) level, and vice versa.
In the interim, the newer gen SSD's have garbage collection routines that are good enough that the absence of TRIM support at the controller level is probably going to be unnoticable for most usage scenarios. It's not the end of the world, you're not damaging your drives, all you're doing is potentially sacrificing some write speed. And if you're the paranoid/OCD type you could always backup the array, break it and perform a secure erase on the individual drives every 3-6 months. But before I even went through that trouble I'd benchmark and see if its actually performing slower than day one -- in most cases and especially with newer drives it probably won't be.
Last edited:
Red Falcon
[H]ard DCOTM December 2023
- Joined
- May 7, 2007
- Messages
- 12,475
Here's what he asked:
Here's what I answered:
So, how was that not what the OP asked and how is that incorrect?
If RAID were enabled, then obviously the TRIM commands would not be sent.
If the hardware RAID controller is acting as a pass-through node/HBA, however, how would the TRIM command not be sent to it?
At that point, the OS would simply see the HDD, not a RAID array through the drivers.
Old Hippie
Supreme [H]ardness
- Joined
- Oct 31, 2005
- Messages
- 6,013
Maybe because the other cheapo SATA6 expansion cards don't do it?
Do you have a link that says different?
Red Falcon
[H]ard DCOTM December 2023
- Joined
- May 7, 2007
- Messages
- 12,475
I don't, but that's why I'm asking.
Is it the driver itself that won't allow the TRIM commands to go through the RAID controller, again, acting as a HBA without RAID enabled, to the SSD?
I'm not saying he's wrong, it just doesn't make sense to me on why TRIM won't work on a single drive, regardless of the controller, especially if RAID is not enabled or present.
Old Hippie
Supreme [H]ardness
- Joined
- Oct 31, 2005
- Messages
- 6,013
Same here. LOL!
The question is way to technical for me but I have yet to see an add-on card that cooperates with TRIM.
Red Falcon
[H]ard DCOTM December 2023
- Joined
- May 7, 2007
- Messages
- 12,475
Just connect the SSD to it, then allow the drive to operate on its own, without enabling RAID, JBOD, or any other onboard function of the card.
This way the RAID controller will act as a HBA, or a pass-through node.
I actually will do this with many FakeRAID controllers for software RAID, but I have yet to test any of these with TRIM on a single SSD.
Please let us know your results once you receive the card.
Old Hippie
Supreme [H]ardness
- Joined
- Oct 31, 2005
- Messages
- 6,013
Just curious, what results are you looking for?
Red Falcon
[H]ard DCOTM December 2023
- Joined
- May 7, 2007
- Messages
- 12,475
^ Basically if he gets it to work or not.
Old Hippie
Supreme [H]ardness
- Joined
- Oct 31, 2005
- Messages
- 6,013
That's what I'm asking.
How will he know?
Are you saying to run speed tests?
AFAIK you can't tell if the drive receives the command, only thats it's been sent.
What tests/results should he be looking for?
Red Falcon
[H]ard DCOTM December 2023
- Joined
- May 7, 2007
- Messages
- 12,475
You should be able to see that the drive has TRIM enabled at least, by use of Intel's SSD tools.
However, this may not honestly show that the TRIM commands are being received as you've stated, which is why I was hoping he would share his results with us.
Old Hippie
Supreme [H]ardness
- Joined
- Oct 31, 2005
- Messages
- 6,013
You can only show the TRIM command being sent but there's no way to tell if it's working.
TRIM is just a faster GC and should happen immediately when given the command.
Why ask the OP for something none of us can even quantify?
Trim does not pass through a LSI or Areca RAID card regardless of what mode the drive is in. Window's drive requests like trim are sent through the RAID card's "driver" and since the in-between OS and hardware driver does not know what a trim is, the command is not relayed to the SSD. How do I know the SSD is not receiving the trim command? I can monitor what our Micron SSD's are doing through a monitoring port and it will display if it gets and runs a trim command (or other drive functions). They don't trim when connected to an LSI or Areca. At least not with the RAID cards I have tested with.
Red Falcon
[H]ard DCOTM December 2023
- Joined
- May 7, 2007
- Messages
- 12,475
That makes sense, but what stops the SSD from receiving TRIM commands on the mobo SATA controller's driver?
What's the difference? Both the hardware RAID controller and the mobo SATA controller have drivers, so why does one pass on TRIM commands yet the other doesn't?
I'd really like to know because that's currently my only hang-up with this issue.
I'm definitely not saying you're wrong, I believe you, but I just need to know the details of why.
A raid controller may present drives to the O/S in JBOD/passthrough mode but the disk layer almost always hooks to the generic microsoft SCSI driver, which isn't TRIM enabled/aware, whereas plain-jane intel SATA ports on the motherboard hook the disk layer to the generic microsoft ATA driver. And it's not even a matter of it being a RAID card -- even low cost add-in cards that advertise themselves as SATA cards, the O/S will hook the disks to the generic SCSI driver. This just seems to be the nature of third party storage drivers and a side effect of how they interact with the O/S.
Lastly, it seems the issue isn't as simple as a SATA command being allowed to pass through to a drive or not - if it were we would already see far more widespread TRIM support among third party vendors. Intel themselves continue to struggle with real TRIM support in RST.
SSD connected to motherboard SATA port (Intel) -- TRIM SUPPORTED
SATA disk connected to Areca 1880i RAID controller in Passthrough (JBOD) mode -- TRIM NOT SUPPORTED
* Would make no diff if this were an SSD - SCSI driver would still be in effect
Last edited:
Red Falcon
[H]ard DCOTM December 2023
- Joined
- May 7, 2007
- Messages
- 12,475
odditory, thank you for that info, that explains things much better and answers my question in full.
That makes much more sense to me now, thanks.
That makes much more sense to me now, thanks.
A lot more info here... http://en.wikipedia.org/wiki/TRIM
Since SCSI has the "UNMAP" command in the spec which is supposedly analogous to TRIM, I'm actually curious if Windows 8 and Windows Server 8 will manage to implement TRIM type functionality in the new version of the generic microsoft driver for SCSI disks.
Since SCSI has the "UNMAP" command in the spec which is supposedly analogous to TRIM, I'm actually curious if Windows 8 and Windows Server 8 will manage to implement TRIM type functionality in the new version of the generic microsoft driver for SCSI disks.
Last edited:
Well I got the card installed and confirmed that TRIM will not pass through, I had the OS loaded from a conventional HDD and only have the SSD connected to the 9265, win7 doesn't even initialize or see the SSD without installing the LSi drivers for the card, once I installed it the SSD can be seen by window, but the Samsung SSD Magician can not recognize the drive because it is being connected to the card, so no TRIM allow....
The generic problem with trim for a complex RAID of SSD's is one of timing/scheduling. During a trim, SSD performance suffers a large degradation of performance as it runs (the SSD controller has to do a lot of work in a trim). While a trim done on an individual disk on a generic user PC is not a big deal as it's over quickly and the user is doubtfully to even see much impact, the same trim on a heavy-use server array can have far greater impact to performance, especially depending on the type of RAID in use. A lot of calculation goes into ensuring the drives in some types of RAIDs are synced.
Throw in a trim that degrades performance by itself while it is running and couple it with having a complicated RAID having to recalculate the drive sync because of the way the SSD's handles/reports data, and you can have a mess real fast especially if it's a multi user server. So for example, if a server is running its RAID 24x7 under load, there is NO good time to trim the drives. Even if the server manages to get a few seconds/minutes of idle time, will it be enough idle time to actually run a trim and have it complete in time? So basically, everyone just says "screw the trim" for a RAID. Better running at 85% constantly all the time versus some of the time, 99% efficiently, but at other times really poorly because of trim kicking in.
Performance-over-time consistency for a RAID is generally more important for how the majority of these high-end RAID cards are used. Trim can throw that RAID performance consistency for a loop.
If you want to see how a trim can impact SSD performance, here's a tool to manually initiate a trim: http://ssd.windows98.co.uk/downloads/ssdtool.exe . Obviously, it only "initiates" the trim, the controller/SSD must still support the function. Initiate a trim and run a disk benchmark and you will see a big impact somewhere. As I mentioned, this big impact only hits for a short time (so it's not gonna affect every area of a longbenchmark, so like one test portion of a ASSSD run will show a big whack). This "big whack" to SSD performance while it's running get amplified in complicated RAIDs. Until they figure out how to handle the timing/scheduling/RAID parity calculations aspects, it's doubtful it's gonna show up on most RAID cards as a generic standard any time soon.
Throw in a trim that degrades performance by itself while it is running and couple it with having a complicated RAID having to recalculate the drive sync because of the way the SSD's handles/reports data, and you can have a mess real fast especially if it's a multi user server. So for example, if a server is running its RAID 24x7 under load, there is NO good time to trim the drives. Even if the server manages to get a few seconds/minutes of idle time, will it be enough idle time to actually run a trim and have it complete in time? So basically, everyone just says "screw the trim" for a RAID. Better running at 85% constantly all the time versus some of the time, 99% efficiently, but at other times really poorly because of trim kicking in.
Performance-over-time consistency for a RAID is generally more important for how the majority of these high-end RAID cards are used. Trim can throw that RAID performance consistency for a loop.
If you want to see how a trim can impact SSD performance, here's a tool to manually initiate a trim: http://ssd.windows98.co.uk/downloads/ssdtool.exe . Obviously, it only "initiates" the trim, the controller/SSD must still support the function. Initiate a trim and run a disk benchmark and you will see a big impact somewhere. As I mentioned, this big impact only hits for a short time (so it's not gonna affect every area of a longbenchmark, so like one test portion of a ASSSD run will show a big whack). This "big whack" to SSD performance while it's running get amplified in complicated RAIDs. Until they figure out how to handle the timing/scheduling/RAID parity calculations aspects, it's doubtful it's gonna show up on most RAID cards as a generic standard any time soon.
Last edited:
Red Falcon
[H]ard DCOTM December 2023
- Joined
- May 7, 2007
- Messages
- 12,475
Thanks for letting us know.
Old Hippie
Supreme [H]ardness
- Joined
- Oct 31, 2005
- Messages
- 6,013
There's the explanation I've read before.
While you can initiate a TRIM command I have yet to see any graphs (ASSSD or otherwise) that can detect a difference.
I have seen a few for GC but that's a different story.
All SSDs since they became mainstream (ditching SLC for MLC memory) have some sort of GC, just like they have wear leveling. With MLC, they have to.
You can only show the TRIM command being sent but there's no way to tell if it's working.
TRIM is just a faster GC and should happen immediately when given the command.
Why ask the OP for something none of us can even quantify?
Trim isn't a faster GC. Trim gives (far) more garbage to the collector, that's it.
And when a trim command is sent and received, nothing is forcing the SSD to act on it immediately, it can put in a table that this space is now available to the GC, and wait till it's appropriate (idle time, or every X hours, or every XX GB written) for the collection.
Old Hippie
Supreme [H]ardness
- Joined
- Oct 31, 2005
- Messages
- 6,013
I guess I'm thinking faster because the drive can respond immediately while GC on some SSDs take idle time to respond.
While TRIM does do a little better job I can post my RAID0 ASSSD scores that show no performance decrease from the day they were installed @ 10 months ago.
The proof is in the pudding.
Yes, it's somewhere on the Microsoft blogs but they have truely baked both TRIM & UNMAP into the storage layers this time around.
This includes issuing a Trim command on the contents of a VHD and having it propagating to the underlying storage whatever it is. It's actually how Storage spaces does it's thin provisioning, once a slab has been emptied via using Tim to signal it is empty entire slabs can be deallocated from the pool. The dedupe process was also explicitly explained as being aware of it.
Old Hippie
Supreme [H]ardness
- Joined
- Oct 31, 2005
- Messages
- 6,013
Aesma, I've never heard this before.
How about a link?
I don't have a link handy, but it's simple to understand. SSDs conform to the SATA norm, but they aren't hard drives. In fact, they emulate hard drives. That's why you have to align, why defrag utilities show something that doesn't relate to the real state of the drive, etc. So, the SSD does basically whatever it wants, and every manufacturer does it its way.
SSDs have a table of allocated & unallocated flash to manage their provisioned flash and for GC to work, with basically two states : free of used. GC will then shuffle free sectors to have fully free pages ready for full speed writes.
A logical way to implement trim is to use that same table : when a trim command is received, saying "sector this to that is free", the table is updated. Then, GC will do its usual routine. An advantage of this is that the GC can work only on entirely free pages according to this table, instead of blindly freeing all the sectors. Freeing all the sectors could mean a lot of work, shuffling of data, also causing write amplification (what happens with GC/wear leveling when there is no more free space and no trim).
In fact I would say that if trim causes slowdowns, it's probably exactly what's happening, and that's not good. SSDs are all about speed, after all. And most current controllers manage well enough to free pages on the fly if needed, that if doing it in advance causes slowdowns, it would be pretty stupid to do it at all.
SSDs have a table of allocated & unallocated flash to manage their provisioned flash and for GC to work, with basically two states : free of used. GC will then shuffle free sectors to have fully free pages ready for full speed writes.
A logical way to implement trim is to use that same table : when a trim command is received, saying "sector this to that is free", the table is updated. Then, GC will do its usual routine. An advantage of this is that the GC can work only on entirely free pages according to this table, instead of blindly freeing all the sectors. Freeing all the sectors could mean a lot of work, shuffling of data, also causing write amplification (what happens with GC/wear leveling when there is no more free space and no trim).
In fact I would say that if trim causes slowdowns, it's probably exactly what's happening, and that's not good. SSDs are all about speed, after all. And most current controllers manage well enough to free pages on the fly if needed, that if doing it in advance causes slowdowns, it would be pretty stupid to do it at all.
Old Hippie
Supreme [H]ardness
- Joined
- Oct 31, 2005
- Messages
- 6,013
Thanks, I appreciate the reply.
While your logic is sound I do know that all controllers are different and official/varified specs are far and few.
I have inquired elseware and it seems that SF controllers do work like that but I couldn't get confirmation on others.
I was just wanting a link to confirm that all controllers used that protocol.
I run mine in RAID0 so TRIM doesn't matter but the more knowledge is always a good thing.
While your logic is sound I do know that all controllers are different and official/varified specs are far and few.
I have inquired elseware and it seems that SF controllers do work like that but I couldn't get confirmation on others.
I was just wanting a link to confirm that all controllers used that protocol.
I run mine in RAID0 so TRIM doesn't matter but the more knowledge is always a good thing.