DSM 7.1 DSM7.1 introduces new drive vendor-locking parameters

Currently reading
DSM 7.1 DSM7.1 introduces new drive vendor-locking parameters

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:
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 "
because DSM smartctl output viewed this:
230 Media_Wearout_Indicator 0x0032 001 001 --- Old_age Always - 0x015d011e015d # in decimal = 1498962329949
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
 
@jeyare

For whatever reason the log is almost completely empty. This is the sum total of the log and does not seem to reflect anything useful:

Code:
Wed May 4 15:22:12 2022 0x475c388 Warning:  -- Failed to download disables and quirks for "WDC WDS400T2B0A-00SM50" "411030WD" "inbox"
Wed May 4 15:22:13 2022 0x475c188 Critical:  -- Found task "Run DashboardTHINK_User"  info:  0
Wed May 4 15:22:13 2022 0xf301070 Critical:  -- Found task "Run DashboardTHINK_User"  info:  0
Wed May 4 15:22:14 2022 0x1e7d5e0 Warning:  -- js: "[Vuetify] [UPGRADE] 'v-content' is deprecated, use 'v-main' instead.\n\nfound in\n\n---> <VMain>\n       <VApp>\n         <App>\n           <Root>"
Wed May 4 15:22:14 2022 0x1e7d5e0 Warning:  -- js: "[Vuetify] [UPGRADE] 'timeout=\"0\"' is deprecated, use '-1' instead.\n\nfound in\n\n---> <VSnackbar>\n       <VMain>\n         <VApp>\n           <App>\n             <Root>"
Wed May 4 15:24:06 2022 0x1e7d5e0 Critical:  -- js: "TypeError: Reflect.getPrototypeOf called on non-object"

☕
 
@jeyare

For whatever reason the log is almost completely empty. This is the sum total of the log and does not seem to reflect anything useful:

Code:
Wed May 4 15:22:12 2022 0x475c388 Warning:  -- Failed to download disables and quirks for "WDC WDS400T2B0A-00SM50" "411030WD" "inbox"
Wed May 4 15:22:13 2022 0x475c188 Critical:  -- Found task "Run DashboardTHINK_User"  info:  0
Wed May 4 15:22:13 2022 0xf301070 Critical:  -- Found task "Run DashboardTHINK_User"  info:  0
Wed May 4 15:22:14 2022 0x1e7d5e0 Warning:  -- js: "[Vuetify] [UPGRADE] 'v-content' is deprecated, use 'v-main' instead.\n\nfound in\n\n---> <VMain>\n       <VApp>\n         <App>\n           <Root>"
Wed May 4 15:22:14 2022 0x1e7d5e0 Warning:  -- js: "[Vuetify] [UPGRADE] 'timeout=\"0\"' is deprecated, use '-1' instead.\n\nfound in\n\n---> <VSnackbar>\n       <VMain>\n         <VApp>\n           <App>\n             <Root>"
Wed May 4 15:24:06 2022 0x1e7d5e0 Critical:  -- js: "TypeError: Reflect.getPrototypeOf called on non-object"

☕

ok, shared

In the WinOS use pls:
Code:
msinfo
and paste here from the System Summary table:
OS Name:
Version:

An example:
OS Name Microsoft Windows 10 Home
Version 10.0.19043 Build 19043
 
WD - this is the same bunch of idi.ts
Without knowing the system where you tested their SSDs, even if you used them in another HW / OS, they will just wait.
Which, of course, has nothing to do with how MWI is calculated. The final interpretation is the problem.
 
copy/paste

We are always straightforward and respect your experience with IT technologies however as the manufacturer of the product there are specific procedures that needs to be followed for escalations in order to inform relevant teams to investigate an incident.
My point:
Each form has its own fields that need to be filled out. Do not fill in the fields, you will not see the Next/Confirm button.

So WD 2nd level support is waiting for important information about the OS, even though they know very well that it has nothing to do with the OS. But the form contains the empty field, and it is not possible to continue.

“Ordnung muss sein!”

Further evidence that this planet is overpopulated and overemployed. Most people do something they don't enjoy at all. This creates the chain reactions we see every day. Everywhere. Like this one.

Btw: Syno has already passed to the 2nd level. It took almost 3 weeks to fight over who has the bigger ego = Synology 1st line support always wins. Who would care what the customer wants?
 
WD 2nd level is working on. Great

Btw, one pearl from the last ticket status from WD support:

You are kindly asked not to reply this email until we reply you back for an update otherwise a re-escalation may be required.
If you have any further questions, please reply to this email and we will be happy to assist you further.

Should I stay or should I go now
If I go there will be trouble
And if I stay it will be double
So you gotta let me know
Should I stay or should I go?

:unsure:
 
Btw: Syno has already passed to the 2nd level. It took almost 3 weeks to fight over who has the bigger ego = Synology 1st line support always wins. Who would care what the customer wants?

The escalation layer at Syno Level 1 have asked for the debug.dat for my NAS (which I have provided). Hopefully once through L2 they will ask L3 (ie @jeyare) as to what has gone wrong and what they need to do to fix it!
 
to the future:
- create the debug.dat
- rename it to "debug.zip" or any other compression container
- unzip it
- and see what they ask .... btw all the files you can find in your NAS directly, in the same structure.
- they asked it about 3 times in their entire support history for my NASes. And I always wrote - Nope - what specific files do you need?
- Btw: They do not need more than 8 files for this thread (MWI problem).
- but I understand why they do it that way - 90% of NAS users do not know that SSH even exists.
- Of the remaining 10%, only about half understand working with SSH.
- so they make it easier for 95% of users to ask for a whole DSM dump.
Single support for all is killing.
 
Last edited:

Version: 7.1-42661 Update 2​


(2022-06-01)

Important notes​

  1. Your Synology NAS may not notify you of this DSM update because of the following reasons. If you want to update your DSM to this version now, please click here to manually update it. Only Synology NAS with DSM 7.1 installed can be updated to this version.
    • The update is not available in your region yet. The update is expected to be available for all regions within the next few days, although the time of release in each region may vary slightly.
    • Your DSM is working fine without having to update. The system evaluates service statuses and system settings to determine whether it needs to update to this version.
  2. This update will restart your Synology NAS.

Compatibility & Installation​

  1. When an SSD's firmware version doesn't support the S.M.A.R.T test, the system will disable related functions.

I wonder about the bit I highlighted. For sure, it is disingenuous as you find it practically impossible to find SSD firmware that doesn't support the SMART test. As we know, Synology is selectively updating smartmon in a way that prevents normal updates to non-Synology SSDs.

DSM7.1-U1 brought about new software features to distinguish between Syno and non-Syno drives. Even if the smartmon version used by Synology is correct for the drive, DSM now does something different - it now reads the SMART data, logs it and then, depending on the flags they set, they can set an artificial compatibility warning that, to the GUI, makes it appear that SMART is not fully supported due to the not_in_support flag being set. Ouch.

With the not_in_support flag set it moves to the compatibility_action parameters. In my case these are:

Code:
{ "discard_from_web": false, "notification": false, "selectable": true, "alert": true, "ui_compatibility": "not_in_support" }

Of note, Synology also included a way to "unlock" their drive vendor locking. This is in a different parameter, subtly titled force_compatability.

Another feature of note is that DSM7.1-U1 reads and logs the contents of the SMART data it claims to be incompatible with. Curiously DSM logs the serial number of the drive and then substitutes its own UI-specific serial number to keep track of it. The line of code that does this subterfuge logs this new drive-specific serial number under ui_serial.

Synology is doing an awful lot of work under the hood to change normal SATA drive monitoring into a web of changes to dissuade or prevent the use of non-Synology drives. For those not expecting these changes to impact them at some point may be rather disappointed in the revisions to come.

Anyway, I will try the latest firmware 7.1-U2 and we will see if it removes the 'critical' warnings on my drives triggered by -U1. I suspect it may (standby for disappointment) but other SMARt data may vanish from view. I could be wrong...

☕
-- post merged: --

Ok, disappointment it it. The GUI SMART Health Monitoring is still messed-up.

You can run a SMART QT via the GUI and, post-test, the drive will report itself as 'Healthy':

 2022-06-01 at 16.51.11.png



However, to DSM Storage Manager it still shows all my SSD Healths as 'Critical':

 2022-06-01 at 16.51.58.png


I despair at their clumsy attempts to frag their own customers.

☕
 
I don't believe it would (patch) get into this U2 release. If so, it will only confirm the inconsistency in SW Dev.
I'm afraid - it will continue.
Anyway, this will be a very bad signal from Syno Product Management.

I'll keep my fingers crossed for you. I did this whole exercise and support because I recommended someone a quick way to RS1221+, and now I'm waiting for this hell to happen here.
 
Last edited:
Gents,

After 21 days of stretching with Synology, I finally received a normal message from 2nd line support:

sorry for the delay and thanks for your patience. Our headquarter confirmed that there has been a light discussion with WD for this issue. However it should be solved in the newer version of DSM. But meanwhile the solution is simple.

Just click update in storage manager, this should solve your issue.
If that fails please give us remote an dthe debug.dat log so we can furthher analyze

1654164517095.png


-------------------------------------
tested on my DSM6:

1654164969219.png


AS-IS:
Bash:
smartctl -V
smartctl 6.5 (build date Mar 2 2021) [x86_64-linux-3.10.105] (local build)
smartmontools release 6.5 dated 2015-06-04 at 16:29:41 UTC

then:
Bash:
grep -w "VERSION:" /var/lib/smartmontools/drivedb.db
{ "VERSION: 7.3 $Id: drivedb.h 5382 2022-05-10 20:13:16Z dipohl $",

or here:
1654164730634.png

----------------------------------------------------------------------------------
After the 'UPDATE NOW' button action:

1654165487645.png


the date is changed obviously

Bash:
smartctl -V
smartctl 6.5 (build date Mar 2 2021) [x86_64-linux-3.10.105] (local build)
smartmontools release 6.5 dated 2015-06-04 at 16:29:41 UTC
no change here

then:
Bash:
grep -w "VERSION:" /var/lib/smartmontools/drivedb.db
{ "VERSION: 7.3 $Id: drivedb.h 5387 2022-05-22 14:52:46Z chrfranke $",
changed to version release date (May 22nd) and new user name (release user)

or here:
1654165773802.png

Note: just expected drivedb.* files were changed
synodrivedb.* unchanged

last check - what was changed in the DB content related to WDS (problematic SSD) and ID230 (MWI):
"-v 230,hex48,Media_Wearout_Indicator "
vs broken version:
"-v 230,hex48,Media_Wearout_Indicator "
nothing

@Robbie
it is up to you

1. If the 'UPDATE' button does something other than just update DB, it should work and it's 'broken' in the DSM code (as was expected).

2. If that doesn't work for you, nothing is changed in the DB in favour of your SSD = it's 'broken' in the DSM code (as was expected). Then you need to wait for the new DSM update release - as was described in the 2nd level support answer.

Conclusion:
This only confirms the fact that the level of 1st line support in Synology is terrible and any power user has to "tolerate" their ego-game and insist on the requested condition that they apply the ticket for the 2nd level ASAP.
Do not send them any debug.dat. It contains dangerous information that you should never just leave your NAS somewhere where it is not under your control. Ask them to tell you exactly what they want.
I have to admit, the pressure from another floor also helped a bit (which is also bad news for all Syno owners). Syno support received detailed instructions from me for the solution and they kept it on the 1st line support for 14 days. When you read the 2nd level response, they immediately understood the issue. Bad, bad, bad.

Never mind, I'm glad I helped.

:coffee:🥃
 
Last edited:
The UPDATE button on Storage Manager database didn't work either. Synology's 'next level' of support is now saying there is nothing wrong in the SMART data (even after acknowledging it before and receiving a copy of the correct results via the WD Tool, amongst others) and are pointing me towards WD...

They also drew doubt on the reported life remaining given their age but they carefully overlook the NAND writes data etc included with the SMART data and the remaining spare blocks that all suggest that my SSDs have barely scratched-the-surface of their predicted lives.

I have asked them to articulate exactly what issue I should report to WD, given the data collected so far.

Head vs brick wall. 🤯


My data following the drive database update (02 Jun 22).

Smartctl Version:

Code:
Rob@Rivendell:~$ smartctl -V
smartctl 6.5 (build date Oct  7 2021) [x86_64-linux-4.4.180+] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

smartctl comes with ABSOLUTELY NO WARRANTY. This is free
software, and you are welcome to redistribute it under
the terms of the GNU General Public License; either
version 2, or (at your option) any later version.
See http://www.gnu.org for further details.

smartmontools release 6.5 dated 2015-06-04 at 16:29:41 UTC
smartmontools SVN rev is unknown
smartmontools build host: x86_64-pc-linux-gnu
smartmontools build with: GCC 8.5.0
smartmontools configure arguments:  '--host=x86_64-pc-linux-gnu' '--target=x86_64-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--prefix=/usr' 'build_alias=i686-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'target_alias=x86_64-pc-linux-gnu' 'CXX=/usr/local/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-wrap-g++' 'LDFLAGS= -Wl,-z,relro -Wl,--as-needed -Wl,--no-undefined' 'CC=/usr/local/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-wrap-gcc' 'CFLAGS=-DSYNOPLAT_F_X86_64  -include /usr/syno/include/platformconfig.h -DSYNO_ENVIRONMENT -DBUILD_ARCH=64 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DSYNO_RUNNING_DSM_BUILD_SYSTEM -g -pipe -fstack-protector-strong -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2  -Wno-unused-result -fexceptions -fstack-clash-protection -fcf-protection=full -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE' 'PKG_CONFIG_PATH='
Rob@Rivendell:~$

Drive database:

Code:
Rob@Rivendell:~$ grep -w "VERSION:" /var/lib/smartmontools/drivedb.db
  { "VERSION: 7.3 $Id: drivedb.h 5387 2022-05-22 14:52:46Z chrfranke $",
Rob@Rivendell:~$

Various drive databases listed on DSM7.1-U2:

Code:
Rob@Rivendell:~$ ls /var/lib/smartmontools/
drivedb.db      drivedb.db.new   synodrivedb.db      synodrivedb.db.new
drivedb.db.bak  drivedb.version  synodrivedb.db.bak  synodrivedb.version
Rob@Rivendell:~$

Not exactly standard...
 
apparently, two different teams at Synology addressed this issue. Great resources utilization example. Great job Synology.

I will wait for this answer, maybe I'll learn more about smartmontools:
I have asked them to articulate exactly what issue I should report to WD, given the data collected so far.

Conclusion:
both DSM 6 and 7 use:
- the same smartmontools source drivedb.h source (github) as expected
- the same custom home brewed (cleaned) dirivedb.db as resul from the source drivedb.h (big question why they clear some rows from the original)
- the same source of update od the drivedb.db.

Which only confirms that DSM6 is not generally behind the update of the DSM7 process in this particular matter. Which creates an assumption that the patches of other parts, which are logically common in both DSMs, are similarly approached.

What makes sense to me.

… and someone wrote in this forum that he appreciates that the box from Synology also has support, unlike the custom build HW NAS and a system like TrueNAS Core.
Nothing is perfect, but enough is enough.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

I'd like to format some external USB-drives from my NAS, however it only seems to quick-format them, not a...
Replies
0
Views
487
I found this. Interesting as it seems many modern synology boxes should be able to sync 1-5million files...
Replies
1
Views
1,222
  • Question
When you add share folders on your local PC/Mac, it lists your share folders in the order you added them...
Replies
0
Views
899

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top