SSD Trim support driver solution ESB2 xw workstations

[SDH]

EDIT:  IT TURNS OUT THAT THIS SAME ISSUE EXISTS IN THE W10PRO64 INSTALL ON THE HP XW WORKSTATIONS, AND LIKELY OTHERS.  SEE THE BOTTOM POST FROM 7/16.

I've been working on a project to help another member of this forum, and just made a significant breakthrough related to the xw workstations, their Storage Controllers driver version, and SSD TRIM support.  I discovered this while working with Hard Disk Sentinel Pro version 4.60, the free trial version.

It turns out that the Sentinel program can probe a SSD and see what parts of the usual special OS components for SSD optimization are installed, and most importantly whether TRIM for the SSD is actually working.  In their FAQ they explain that an OS may have the TRIM function supported, but that TRIM may in fact be disabled despite the OS having received the proper command to enable it.  This failure is due to either the hardware (the storage controller chipset may just not be able to do it) or software (the driver version for that chipset may be incapable, but a newer driver could work fine).

I came across exactly that driver issue, and bet few of us knew this might be the case.  The xw6400, xw6600, xw8400, and xw8600 workstations all use the same ESB2 storage controller chipset, and the xw6600 I was working on with an Intel 320 series SSD returned a response to my probe with Hard Disk Sentinel that TRIM was supported but disabled.  Another xw6600 with same SSD reported TRIM was supported and enabled.  The first was using ESB2 drivers 8.6.2.1315 older drivers, and the second was using my favorite "best" ESB2 drivers 10.0.0.1046.

I ran the normal TRIM check command on the first xw6600 ( fsutil behavior query DisableDeleteNotify) and it came back 0 (which means TRIM is enabled in my OS W7Pro64).  Run that cmd as an administrator, using an elevated command prompt.  It turns out that 0 response from the OS does not mean TRIM is actually working.... it just means that it could work if the hardware and the driver both were sufficient.

I then updated my ESB2 Storage Controllers driver via Device Manager to the 64-bit version 10.0.0.1046, re-ran Hard Disk Sentinal, and now have TRIM both supported and enabled.

This is a significant finding..... before, with the ESB2 8.6.2.1315 drivers, I could manually run TRIM from the Intel ToolBox software, but now the OS can run TRIM automatically, at regular intervals.  I'm just lucky that I had already settled on that 10.0.0.1046 set as my go-to drivers for clean installs long ago.  Those, by the way, are not what you get from the HP installer DVDs.  I got them from Intel.  Target to the x64 folder from Device Manager for the browse method driver update, assuming you're using a 64-bit OS.

Note the arrows below, with the 3 pics showing (1) a clone build onto a HDD from a HDD source image, then (2) a clone build onto a SSD from the HDD source image ( with the older drivers), and finally (3) a clone build onto a SSD from the HDD image (with those newer drivers installed).

Old drivers, and note that either Acronis or the OS added the SSD-specific components automatically:

Now, with the newer 10.0.0.1046 drivers:

You can use a trial version of Hard Disk Sentinel to confirm whether or not your SSD's TRIM feature is actually working automatically from the OS, and if not then try some newer storage controllers drivers and check again.  I have found Hard Disk Sentinel to be rather intrusive, so do not keep it installed other than for this type of testing.

[old_geekster]

Thank you for the great information.  I don't help much with the Workstations, but it will help if I do.

[SDH]

Happy to help.  I was so surprised by this finding and the importance of it that I wanted to provide our forum members the FAQ from the Hard Disk Sentinel web site that deals with the issue.  I always had presumed that I could just do the elevated cmd check and be sure that TRIM was working if I got the response "0" back from that.  Here it is, in full, with a few slight edits for clarity:

"I believe TRIM is enabled (the fsutil command line utility shows that), but Hard Disk Sentinel shows it is DISABLED. Why?

There is a big difference between the TRIM feature being enabled and being active.  Enabled just means that the OS will attempt to send the TRIM command to the SSD device (via the controller/driver where the SSD is connected), but that does not guarantee that the SSD will actually receive that TRIM command.

The fsutil utility shows if the operating system in general uses the TRIM function, or not.  The result of this is completely useless.  For example,  it returns 0 (TRIM "working") even if there is no SSD present in the system.  If the result is 0, it means that the operating system is prepared to send the TRIM command for the proper device (an SSD with TRIM function supported).

The question is: does the hard disk controller (and its driver) pass this command to the SSD(s) used in the system, or block it?
The problem is that some hard disk controllers (and their drivers) may block the TRIM command, and not pass it to the SSD even if TRIM is supported by the SSD.  This is the same concept as with the "Acoustic management" command for hard disks which also may be blocked when attached to some hard disk controllers.

For example, if you'd have two or more SSDs (all supporting TRIM) in your system, it may be possible that the TRIM command will be transferred properly to one of them but not for the other(s) if the SSDs are connected to different disk controllers.

Hard Disk Sentinel checks the real usage of TRIM for each appropriate device (one-by-one).  If it displays "disabled", it means there is a problem with the driver of the hard disk controller (if both the OS and SSD should support TRIM). Usually updating this driver will help.  If not, using a different hard disk controller may also helpful."

There you have it....

Many of us know how to trigger TRIM from our SSD's control software, such as the Intel Toolbox, but some SSDs I have seen from HP don't have such control software, and without the above information I have been assuming things were just being taken care of automatically for our company  W7 and above builds.  Having TRIM actually work is worth the effort.

[SDH · Accepted solution]

I have been preparing a number of W7Pro64 HP xw workstations by running the W10Pro64 activation procedure, and came across the fact that the standard W10Pro64 install places older Storage Controller drivers into the install that have been found previously in W7Pro64 installs to "support" TRIM but to not have automatic OS-controlled regular SSD TRIM functionality enabled.  It has, instead, been "disabled".

It is one thing to run TRIM manually once a month, but you truly should have the OS taking care of that task, and not forgetting.

For those HP workstations that use the ESB2 storage controller chipset and BIOS SATA emulation set to "RAID + AHCI" or "RAID" if that other option is not available (the same driver install results, regardless) this is an issue.  I have not investigated up into the ZX00 or ZX20/ZX40 generations yet because they use other chipsets and drivers for this task.  The ESB2 chipset workstations include the xw6400, xw8400, xw6600, xw8600, plus a bunch more not from HP.

The W10Pro64 install results in the ESB2 driver installed automatically being 8.6.2.1025 with driver date 8/10/10.  When probed with Hard Disk Sentinel the program detects that SSD TRIM is supported but not enabled:

After updating the driver to the more recent 10.0.0.1046 version, dated 9/13/10,  the TRIM functionality for the operating system was both supported and enabled:

I have found Hard Disk Sentinel a valuable tool, but somewhat intrusive, so I only install it for such experiments, and then uninstall.

So, the take home message is the same for these workstations running W10Pro64 as it was when they are running under W7Pro64 (see the posts above, from 1/16).  Update to the 10.0.0.1046 version of the ESB2 Storage Controller driver if you want your SSD to be automatically triggered by W10 for TRIM cleanup regularily. 

Who remembers to do that manually?