Here is the described solution for Syno Devs
Today the 1st line Syno support finally understood to move my request to the 2nd line.
1. location:
/var/lib/smartmontools
2. there are 3 important files;
same size, same date of last modification, but diff content in the first row only (db version by smartmontools):
drivedb.db .... check (below)
drivedb.db.new ..... the same file like drivedb.db incl. the first row mentioned
drivedb.db.bak .... the previous version was left for a fallback by Syno devs (the diff first row)
3. edit the drivedb.db
4. find a row with ""WDC ?WDS" record ... which is about mentioned WD SSDs
5. the record is like this:
Description:
here is the core problem discovered by me (waiting for the WD support confirmation).
There is a defined parameter to read hex48 value (and not raw48) from the 230 MWI row:
because DSM smartctl output viewed this:
001 - is raw48 value format (what isn't OK)
0x015d011e015d - is the hex48 format of the remaining media surface for the wearout (what is OK)
someone in Syno Devs had to make a change in the reading of values from the hex48 to raw48 value =001
As of the previous version, it did not exist.
This approach is contradictory with the original smarmontools drivedb.h record = which was transferred/customized obviously to Synology DSM:
/var/lib/smartmontools/ files mentioned above
---------------------
Just for a comparison - here is a copy/paste from the last version of the original smartmontools diskdb.h:
no need to dump the DSM, everything you can find in your kitchen.
It just depends on what state you have your documentation for SW Devs.
As you can see, this has nothing to do with 3rd party disc support or incompatibility. This is just a consequence of uncontrolled changes to new versions by DSM creators.
You welcome
Today the 1st line Syno support finally understood to move my request to the 2nd line.
1. location:
/var/lib/smartmontools
2. there are 3 important files;
same size, same date of last modification, but diff content in the first row only (db version by smartmontools):
drivedb.db .... check (below)
drivedb.db.new ..... the same file like drivedb.db incl. the first row mentioned
drivedb.db.bak .... the previous version was left for a fallback by Syno devs (the diff first row)
3. edit the drivedb.db
4. find a row with ""WDC ?WDS" record ... which is about mentioned WD SSDs
5. the record is like this:
JSON:
{ "WD Blue / Red / Green SSDs",
"WDC WDBNCE(250|500|00[124])0PNC(-.*)?|"
"WDC ?WDS((120|240|250|480|500)G|[124]00T)(1B|2B|1G|2G|1R)0[AB](-.*)?",
"", "",
"-v 165,raw48,Block_Erase_Count "
"-v 166,raw48,Minimum_PE_Cycles_TLC "
"-v 167,raw48,Max_Bad_Blocks_per_Die "
"-v 168,raw48,Maximum_PE_Cycles_TLC "
"-v 169,raw48,Total_Bad_Blocks "
"-v 170,raw48,Grown_Bad_Blocks "
"-v 171,raw48,Program_Fail_Count "
"-v 172,raw48,Erase_Fail_Count "
"-v 173,raw48,Average_PE_Cycles_TLC "
"-v 174,raw48,Unexpected_Power_Loss "
"-v 230,hex48,Media_Wearout_Indicator "
"-v 233,raw48,NAND_GB_Written_TLC "
"-v 234,raw48,NAND_GB_Written_SLC "
"-v 241,raw48,Host_Writes_GiB "
"-v 242,raw48,Host_Reads_GiB "
"-v 244,raw48,Temp_Throttle_Status "
},Description:
here is the core problem discovered by me (waiting for the WD support confirmation).
There is a defined parameter to read hex48 value (and not raw48) from the 230 MWI row:
JSON:
"-v 230,hex48,Media_Wearout_Indicator "where:
001 - is raw48 value format (what isn't OK)
0x015d011e015d - is the hex48 format of the remaining media surface for the wearout (what is OK)
someone in Syno Devs had to make a change in the reading of values from the hex48 to raw48 value =001
As of the previous version, it did not exist.
This approach is contradictory with the original smarmontools drivedb.h record = which was transferred/customized obviously to Synology DSM:
/var/lib/smartmontools/ files mentioned above
---------------------
Just for a comparison - here is a copy/paste from the last version of the original smartmontools diskdb.h:
JSON:
{ "WD Blue / Red / Green SSDs", // tested with WDC WDS250G1B0A-00H9H0/X41000WD,
// WDC WDS250G1B0A-00H9H0/X41100WD, WDC WDS100T1B0A-00H9H0,
// WDC WDS120G2G0A-00JH30/UE360000, WDC WDS240G2G0A-00JH30/UF300000,
// WDC WDS500G2B0A-00SM50/X61130WD, WDC WDS200T2B0A-00SM50/X61130WD,
// WDC WDS200T2B0A/X61190WD, WDC WDS120G1G0A-00SS50/Z3311000
// WDC WDS500G2B0A-00SM50/401000WD,
// WDC WDBNCE2500PNC/X61130WD, WDC WDBNCE0010PNC-WRSN/X41110WD,
// WDC WDS200T1R0A-68A4W0/411000WR, WDC WDS400T1R0A-68A4W0/411000WR
"WDC WDBNCE(250|500|00[124])0PNC(-.*)?|" // Blue 3D
"WDC ?WDS((120|240|250|480|500)G|[124]00T)(1B|2B|1G|2G|1R)0[AB](-.*)?",
// *B* = Blue, *G* = Green, *2B* = Blue 3D NAND, *1R* = Red SA500
"", "",
//"-v 5,raw16(raw16),Reallocated_Sector_Ct " // Reassigned Block Count
//"-v 9,raw24(raw8),Power_On_Hours "
//"-v 12,raw48,Power_Cycle_Count "
"-v 165,raw48,Block_Erase_Count "
"-v 166,raw48,Minimum_PE_Cycles_TLC "
"-v 167,raw48,Max_Bad_Blocks_per_Die "
"-v 168,raw48,Maximum_PE_Cycles_TLC "
"-v 169,raw48,Total_Bad_Blocks "
"-v 170,raw48,Grown_Bad_Blocks "
"-v 171,raw48,Program_Fail_Count "
"-v 172,raw48,Erase_Fail_Count "
"-v 173,raw48,Average_PE_Cycles_TLC "
"-v 174,raw48,Unexpected_Power_Loss "
//"-v 184,raw48,End-to-End_Error " // Detection/Correction Count
//"-v 187,raw48,Reported_Uncorrect " // Uncorrectable Errors
//"-v 188,raw48,Command_Timeout "
//"-v 194,tempminmax,Temperature_Celsius "
//"-v 199,raw48,UDMA_CRC_Error_Count " // SATA CRC Errors
"-v 230,hex48,Media_Wearout_Indicator " // Maybe hex16
//"-v 232,raw48,Available_Reservd_Space"
"-v 233,raw48,NAND_GB_Written_TLC "
"-v 234,raw48,NAND_GB_Written_SLC "
"-v 241,raw48,Host_Writes_GiB "
"-v 242,raw48,Host_Reads_GiB "
"-v 244,raw48,Temp_Throttle_Status "
},no need to dump the DSM, everything you can find in your kitchen.
It just depends on what state you have your documentation for SW Devs.
As you can see, this has nothing to do with 3rd party disc support or incompatibility. This is just a consequence of uncontrolled changes to new versions by DSM creators.
You welcome
️
