007revad

You can create a discussion topic at https://github.com/007revad/Synology_HDD_db/discussions

There is. First replace the existing drive database files with a clean copy. Download https://global.synologydownload.com/download/DriveUpdate/SynoOfflinePack/731/SynoOfflinePack-ds918%2B-731.sa to your NAS. Go to Storage Manager > HDD/SSD > Settings > Advanced. Go to the Drive Database section and click Manual Update. Click Browse and select the update pack you downloaded. Click Update. Refresh the browser tab then check in storage manager if your drives are supported. If they are still showing "unrecognized firmware" then run https://github.com/007revad/Synology_HDD_db/releases/tag/v3.4.82 via SSH, close and reopen storage manager.

Only if the drives are showing their status as Critical

Someone had either Micron or Crucial NVMe drives and they'd go bad after a few days. They had them replaced a few times then eventually they bought some Samsung NVMe drives and the problems stopped.

In storage manager RAID 1 has a maximum 4 drive limit. All other RAID types have a 65,536 drive limit. https://github.com/007revad/Synology_enable_M2_volume/wiki/RAID-min-and-max-drives

Version 3.4.x of syno_hdd_db.sh allows you to: Create a storage pool on NVMe drives in a PCIe card. Create a storage pool combining NVMe drives in the mobo's M.2 slots and NVMe drives in a PCIe card. Before version 3.4.x you needed to use syno_create_m2_volume.sh to create the storage pool. I used storage manager to create an SHR storage pool spanning 2 NVMe drives in a E10M20-T1 and 1 NVMe in the mobo's M.2 slot. There were a couple of minor GUI issues in storage manager: Storage manager shows both mobo M.2 slots as used even though there is only 1 slot being used. Clicking on either of those M.2 slots opens the info for one of the drives in the PCIe card. I could fix those issues, but I'm busy with other things at the moment. For your 2nd question, storage manager won't let you create a storage pool with different drive types. It is possible to make it work, but why would anyone want to.

/var.defaults/lib/diskaction/diskaction.xml disables SDD TRIM for some SSD models: <disk model="CT.*MX300SSD.*">TRIM_OFF</disk> <disk model="ST.*FM.*3">TRIM_OFF</disk> <disk model="HUSMR16..ASS2(0|3)(0|1|4|5)">TRIM_OFF</disk> <disk model="SNV[0-9]*[a-zA-Z]*">TRIM_OFF</disk> synoinfo.conf has 2 trim settings that should be set to yes: support_ssd_trim="yes" support_trim="yes" Without changing any of the above I have TRIM available on my Intel SSD and WD NVMe drives.

Something like this would work, if grep is available in DSM junior mode: if ! grep 'drive_db_test_url="127.0.0.1"' /etc.defaults/synoinfo.conf; then echo 'drive_db_test_url="127.0.0.1"'; fi drive_db_test_url does not exist in synoinfo.conf unless we've added it, so if it exists it will already be set to "127.0.0.1"

You should add the following to prevent DSM updating the drive databases, which it does after a DSM update and whenever a drive is inserted, and other seemingly random times. synosetkeyvalue /etc.defaults/synoinfo.conf drive_db_test_url="127.0.0.1" synosetkeyvalue /etc/synoinfo.conf drive_db_test_url="127.0.0.1"

@Captainfingerbang This looks like DSM is updating the drive database after it's been edited. @Peter Suh Are you running the script with the -n option?

I've updated my syno_hdd_db script to include smart_test_ignore and smart_attr_ignore when adding, inserting or editing drive entries in the db files. https://github.com/007revad/Synology_HDD_db/commit/f0b44ffbb1501e0a2e80657c5ed49bcb32b7c3eb https://github.com/007revad/Synology_HDD_db/releases/tag/v3.3.74

I was surprised that adding adding all the extra DSM 7.2 information in DSM 7.1.1 db files never caused an issue.

One my HDD models was previously not on the supported list, but I notice it is now. Checking my .db file shows this drive now includes: "smart_test_ignore": false, "smart_attr_ignore": false I'm sure that previously only Synology drives included those lines.

So removing these lines in the default section didn't help?