1

We have a HP Proliant Dl360 Gen8 server with the 420i 2Gg disk controller. (646905-421)

we have a couple of the HP Gen8 200GB 6G SAS SLC SSDs (653078-B21), (they run in RAID1)

We run Debian6 on this server, and HP says that the "trim" command is not supported on this controller.

-How will this affect the speed and lifetime of the SSD? -Does anyone know any controller that might do a better job? -has anyone run similar configuration, can you say anything on the lifetime of disks?

3

You're using (expensive) enterprise SAS SSDs. This drive is OEM by Sandisk, an LB206S, whose specifications show that it's a write-optimized drive. There is no need for TRIM. TRIM is for cheap consumer SATA disks. In addition, your drives are heavily overprovisioned and have their own wearout indicators available.

This is visible from the controller using the Array Configuration Utility, the HP Smart Storage Administrator or the hpacucli and hpssacli command-line utilities. If you have any of the HP Management Agents installed or even ILO-based monitoring, the server will email/SNMP trap on SSD failure or dwindling drive wearout indicator.

An example from a similar same-OEM drive in my system (LB406M, read-optimized). Pay attention to the Usage remaining field or the field that says "Estimated Life Remaining based on workload to date":

  physicaldrive 1I:1:4
     Port: 1I
     Box: 1
     Bay: 4
     Status: OK
     Drive Type: Data Drive
     Interface Type: Solid State SAS
     Size: 400 GB
     Firmware Revision: HPD9
     Serial Number: 00211644
     Model: HP      MO0400FBRWC     
     Current Temperature (C): 28
     Maximum Temperature (C): 56
     Usage remaining: 99.68%
     Power On Hours: 5845
     Estimated Life Remaining based on workload to date: 75863 days
     SSD Smart Trip Wearout: False
     PHY Count: 2
     PHY Transfer Rate: 6.0Gbps, Unknown
  • Why is trim not important (for write performance)? If all the blocks become 'untrimmed', which will happen eventually after enough writes no matter how much you over-provision, any subsequent write to any block will be slower because the write operation will entail an erase followed by the actual write, which is slower that just the actual write, possible only if blocks have been previously trimmed. – Syncopated Apr 6 '17 at 1:27
  • TRIM is not needed with SAS SSDs, as TRIM is simply emulation of unmap SAS command blog.workinghardinit.work/2012/05/23/… – GregC Sep 24 '18 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.