DSM 7.2 Umkonfigurierte Cache Geräte nicht mehr von DSM 7.2 unterstützt

[Heit-Joe]

Hallo liebes Forum,
war ja klar das es irgendwann passiert Habe auf meiner DS70+ heute das Upgrade auf 7.2 installiert. Nun kommt die folgende Meldung


Hatte die Module damals als Speicher konfiguriert und nicht als Laufwerk Cache. Also auf die Daten kann ich noch zugreifen. habe auf dem Cache-Gerät 2 eine virtuelle Maschine laufen. Die funktioniert auch ! Eventuell kann man die Meldung ja weg basteln ?

Vielleicht hat ja jemand eine Idee oder einen Trick auf Lager

Netten Gruß Joe

 

[plang.pl]

Du musst einmal das Script laufen lassen und dann die DS neu starten

 

[Synchrotron]

Als Hintergrund: 7.2 unterstützt jetzt offiziell die Nutzung von NVME SSDs als Volume - aber nur für eine sehr kleine Auswahl von SSDs. Wird ein Volume aus nicht unterstützen SSDs erkannt, wird es nicht platt gemacht - aber es wird als fehlerhaft ausgewiesen.

Das Script stellt den vorherigen Zustand wieder her.

 

[Heit-Joe]

Also falls ich es richtig verstehe packe ich das Script "syno_hdd_db.sh" in den Taskplaner und das läuft dann bei jeden Start der Nas ? Ich brauche nichts umkopieren oder sichern ? Die Daten und die Volumes bleiben heile ? Ist das so korrekt

 

[plang.pl]

Ja, das ist korrekt
Es reicht auch, das Script einmal nach jedem Update zu starten

 

[Heit-Joe]

Super vielen Dank werde das Morgen mal in Ruhe testen. Danke euch

 

[plang.pl]

Viel Erfolg. Gib hier Bescheid, ob es klappt!

 

[Monacum]

@Heit-Joe Man kann das im Aufgabenplaner auch direkt so anlegen, das es jedes Mal beim hochfahren ausgeführt wird. Das musst du auf der ersten Seite bei deiner neuen Aufgabe dann einstellen.

Die Datei lädst du von GitHub herunter und trägst als Einstellung im Aufgabenplaner den Pfad zu dieser Datei und den Dateinamen ein: /volume1/pfad/zur/datei/syno_hdd_db.sh

 

[Heit-Joe]

Kurze Frage noch ... ich wollte erstmal wissen was eigentlich passiert.
Dafür ist unter ssh dieser Parameter zuständig oder

sudo -i /path-to-script/syno_hdd_db.sh -nr --showedits

Also eine Trockenübung

Danke für eure Hilfe

 

[luddi]

Genau so sollte es sein. Laut Kurzbeschreibung im Repository macht der genannte Aufruf genau das.
Es wird nach entsprechenden Devices gesucht und mit -n verhindert dass die Datenbank aktualisiert wird (Trockenübung) und mit dem Optionsparameter --showedits werden die vermeintlichen Änderungen auf der Konsole ausgegeben.

 

[Benares]

Also ich hab das mit "syno_hdd_db.sh -nr --showedits" grad mal probiert. Bei mir wurden die Dateien trotzdem geändert. Na ja, macht ja nichts.
Seid ihr sicher, dass man "-n -r" wirklich zu "-nr" zusammenfassen kann?
Ich weiß, dass es so in der Hilfe so steht, finde aber keine Entsprechung im Code, bin aber auch nicht der Experte für Scripts.

 

[luddi]

@Benares schau dir im Script dazu einmal die Funktion getopt in Zeile 263 an. Diese liefert die options Parameter einzeln zurück bzw. zusammenhängende werden gestückelt.

 

[Benares]

Ok, mag sein, aber wieso wurde trotzdem was geändert?
Und wie er auf den neuen Wert für mem_max_mb kommt, ist mir auch noch nicht klar.

root@DS1522:~# diff /etc.defaults/synoinfo.conf.bak /etc.defaults/synoinfo.conf
81c81
< mem_max_mb="32768"
---
> mem_max_mb="8421376"

 

[luddi]

Zum einen das mag nicht nur so sein, sondern ist definitiv so.

Hier mal ein Beispiel mit getopt.

√ root@host -zsh: ~ $ ./testgetopt.sh -nr --showedits
User input: -nr --showedits

getopt result:  -n -r --showedits --

# while loop through all arguments and shift by one each time
# and process each loop the first argument
Options: -n -r -s --
Processing: -n

Options: -r -s --
Processing: -r

Options: -s --
Processing: -s

Options: --
Processing: --

Bezüglich des anderen Verhaltens, dass dennoch die synoinfo.conf geändert wurde ist mir nicht ganz klar.
Die Prüfung findet hier statt:

    # Check if we disabled drive db auto updates
    url="$(get_key_value $synoinfo drive_db_test_url)"
    if [[ $disabled == "yes" ]]; then
        if [[ $url == "127.0.0.1" ]]; then
            echo -e "\nDisabled drive db auto updates."
        else
            echo -e "\n${Error}ERROR${Off} Failed to disable drive db auto updates!"
        fi
    else
        echo -e "\nDrive db auto updates already disabled."
    fi

Die Frage ist, welche der drei möglichen Informationen wurde bei dir in der Konsole ausgegeben?

1. Disabled drive db auto updates.
2. Failed to disable drive db auto updates!
3. Drive db auto updates already disabled.

Weshalb die synoinfo.conf in dem Fall von -r bzw. --ram geändert wird bin ich auch nicht sicher.
Und was den neuen Wert betrifft, da habe ich die Berechung auch noch nicht versucht nachzuvollziehen.

Hier ab Zeile 1257 geht es los mit set mem_max_mb, aber es wird hier nirgends geprüft ob ein DB Update statfinden darf.

        # Set mem_max_mb to the amount of installed memory
        setting="$(get_key_value $synoinfo mem_max_mb)"
        if [[ $ramtotal =~ ^[0-9]+$ ]]; then   # Check $ramtotal is numeric
            if [[ $bytes == "GB" ]]; then      # DSM 7.2 dmidecode returns GB
                ramtotal=$((ramtotal * 1024))  # Convert to MB
            fi
            if [[ $ramtotal -gt $setting ]]; then
                synosetkeyvalue "$synoinfo" mem_max_mb "$ramtotal"
                # Check we changed mem_max_mb
                setting="$(get_key_value $synoinfo mem_max_mb)"
                if [[ $setting == "$ramtotal" ]]; then
                    #echo -e "\nSet max memory to $ramtotal MB."
                    ramgb=$((ramtotal / 1024))
                    echo -e "\nSet max memory to $ramtotal GB."
                else
                    echo -e "\n${Error}ERROR${Off} Failed to change max memory!"
                fi

Meine Vermutung soweit ich das Script beurteieln kann und die Kommentare richtig interpretiere, dass mit der Option

-n, --noupdate        Prevent DSM updating the compatible drive databases

nur die Drive Datenbanken unter dem Pfad /var/lib/disk-compatibility/ vor einem Update geschützt werden.

Nicht jedoch die RAM settings welche die synoinfo.conf aktualisiert.

-r, --ram             Disable memory compatibility checking (DSM 7.x only),
                        and sets max memory to the amount of installed memory

Aber wenn es da tatsächlich ein Problem oder Widersrpüche gibt, dann würde ich an deiner Stelle ein Issue beim Author in dessen Repository erstellen.


EDIT:
Ich glaube ich muss meine vorherigen Vermutungen nochmals zurückziehen.
So wie ich es nun auch mit Hilfe der Kurzbeschreibung verstanden habe, dass es bei diesem Script kein sogenannten Dryrun gibt. Denn mit der Option --noupdate wird verhindert, dass DSM die Laufwerksdatenbank automatisch aktualisiert.

 

[luddi]

Bezüglich der RAM Größe habe ich den Code analysiert und den relevanten Teil auf meinem System zur Berechung laufen lassen.

Dabei ist folgender Code relevant:

# Get total amount of installed memory
IFS=$'\n' read -r -d '' -a array < <(dmidecode -t memory | grep "[Ss]ize")  # GitHub issue #86, 87
if [[ ${#array[@]} -gt "0" ]]; then
    num="0"
    while [[ $num -lt "${#array[@]}" ]]; do
        check=$(printf %s "${array[num]}" | awk '{print $1}')
        if [[ ${check,,} == "size:" ]]; then
            #ramsize=$(printf %s "${array[num]}" | cut -d" " -f2)
            ramsize=$(printf %s "${array[num]}" | awk '{print $2}')           # GitHub issue #86, 87
            bytes=$(printf %s "${array[num]}" | awk '{print $3}')             # GitHub issue #86, 87

            # Ausgabe
            echo ramsize: "$ramsize"
            echo bytes: "$bytes"
            #################

            if [[ $ramsize =~ ^[0-9]+$ ]]; then  # Check $ramsize is numeric  # GitHub issue #86, 87
                if [[ $ramtotal ]]; then
                    ramtotal=$((ramtotal +ramsize))
                else
                    ramtotal="$ramsize"
                fi
            #else
            #    echo -e "\n${Error}ERROR${Off} Memory size is not numeric: '$ramsize'"
            fi
        fi
        num=$((num +1))
    done
fi

# Ausgabe
echo
echo ramtotal: "$ramtotal"
echo bytes: "$bytes"

Wenn man sich allein diese Informationen mit dmidecode -t memory | grep "[Ss]ize" ausgeben lässt, dann bekommt man auf meinem System folgende Ausgabe:

Size: 8192 MB
Size: No Module Installed
Size: 8192 MB
Size: No Module Installed

Das hat dann zur folge, dass die Zeilen mit der Zuweisung von ramsize und bytes wie folgt in der Schleife ausgegeben werden.

ramsize: 8192
bytes: MB
ramsize: No
bytes: Module
ramsize: 8192
bytes: MB
ramsize: No
bytes: Module

# Und am Schluss steht folgendes in den Variablen
ramtotal: 16384
bytes: Module

In meinem Fall stimmt zwar die nummerische Größe überein, aber die Einheit ist hier fälschlicherweise mit "Module" belegt.
Das kommt daher zustande, weil in der Zuweisung von bytes einfach mit awk der dritte Parameter ausgegeben wird.
Und wir erinnern uns an die obige Ausgabe mit Size: No Module und somit ist der dritte Parameter selbstverständlich "Module".

In meinem Fall geht das in dem nächten Code Abschnitt gut, weil hier z.B. nur geprüft wird ob die Einheit "GB" entspricht oder nicht.

if [[ $bytes == "GB" ]]; then      # DSM 7.2 dmidecode returns GB
    ramtotal=$((ramtotal * 1024))  # Convert to MB
fi

Wer weiß was sonst bei anderen Usern (bzw. Geräten) hier vorkommen mag und schlussendlich in der Varibalen $bytes etwas unbrauchbares steht.
Also ganz wasserdicht ist die Implentierung an dieser Stelle jedenfalls nicht, somit steht schon einmal fest.

Ich denke ich werde den Author hierauf hinweisen, dass zumindest hier Verbesserungspotential besteht.

Und zwar würde ich den Befehl der folgendes ausgibt:

dmidecode -t memory | grep "[Ss]ize"

# Ausgabe
Size: 8192 MB
Size: No Module Installed
Size: 8192 MB
Size: No Module Installed

erstzen durch:

dmidecode -t memory | grep -E "[Ss]ize: [0-9]+ [MG]{1}[B]{1}$"

# Ausgabe
Size: 8192 MB
Size: 8192 MB

Somit ist zumindest sichergestellt, dass nur die Einträge gefunden werden welche auch eine Zahl bei der Größe aufzeigen und die zusätzliche Einschränkung auf MB oder GB am Ende der Zeile.

 

[Benares]

Bei mir liefert

root@DS1522:~# dmidecode -t memory | grep "[Ss]ize"
        Size: 8192 MB
        Size: 32 GB

und dein Code-Block aus #15:

ramtotal: 8224
bytes: GB

 

[luddi]

Da haben wir noch einen Fehler. Denn am Schluss der Schleife wird in der Variable $bytes "GB" stehen und es wird nur diese Einheit berücksichtigt.
Deshalb kommt es in deinem Fall zu dem Wert $ramtotal von 8192 + 32 = 8224.
Und dies multipliziert mit dem Faktor für GB folgt letztendendes 8224 x 1024 = 8421376 bytes.

Ich werde das auch gleich zusätzlich an den Issue Report anhängen, oder einen seapraten erstellen.

 

[luddi]

Issues sind erstellt
Wer das nachverfolgen möchte und auf ein Update wartet kann sich gerne hier informieren.

• Routine of RAM size evaluation not sufficient and might cause issues · Issue #106 · 007revad/Synology_HDD_db (github.com)
• Calculation of mixed units will fail in RAM total size · Issue #107 · 007revad/Synology_HDD_db (github.com)

 

[Heit-Joe]

Vielen Dank

Viel Erfolg. Gib hier Bescheid, ob es klappt!

Hat super funktioniert, jetzt wieder alles ok. Wünsche allen ein schönes Wochenende

 

[Monacum]

Issues sind erstellt

Ist im Release Candidate wohl jetzt auch gefixt:

v3.1.59-RC​

Repository: 007revad/Synology_HDD_db · Tag: v3.1.59-RC· Commit: 9f78eb7 · Released by: 007revad

v3.1.59

• Added enabling E10M20-T1, M2D20 and M2D18 for DS1821+, DS1621+ and DS1520+.
• Added enabling M2D18 for RS822RP+, RS822+, RS1221RP+ and RS1221+ for older DSM versions.
• Fixed enabling E10M20-T1, M2D20 and M2D18 cards in models that don't officially support them.
• Fixed bugs where the calculated amount of installed memory could be incorrect:
  • If last memory socket was empty an invalid unit of bytes could be used. Issue #106
  • When dmidecode returned MB for one ram module and GB for another ram module. Issue #107
• Fixed bug displaying the max memory setting if total installed memory was less than the max memory. Issue #107