DSM 4.0 Beta - Erfahrungen, Probleme, Bugs

[JoachimS]

Gute Idee. Habe ich gemacht, hoffe Synology inkludiert die Module.

 

[itari]

Normal ist es ja nicht und die Beta lief jetzt gut eine Woche bei ihm.

wir gehen davon aus, dass es ein Backup der Daten gibt und man die Platten platt machen kann, richtig?

dann doppelter RESET und die Beta-Firmware neu installieren

Itari

 

[Christian72D]

wir gehen davon aus, dass es ein Backup der Daten gibt und man die Platten platt machen kann, richtig?

Nein, das System ist gerade mal drei Wochen alt, um Backups hat er sich noch nicht gekümmert.

 

[itari]

Nein, das System ist gerade mal drei Wochen alt, um Backups hat er sich noch nicht gekümmert.

dann würde ich als erstes versuchen, die Daten an einem PC auszulesen und zu sichern

Itari

 

[xus01]

Hallo,

mit der Beta hatte ich jetzt schon zwei Mal einen Volumenabsturz (Raid0) an meiner DS212+. Leider habe ich dabei einige Daten verloren :-(
Der SMART Test hat keinen Defekt der Festplatten festgestellt. Ich werde jedenfalls in Zukunft auf eine Betafirmware verzichten.

 

[itari]

Hallo,

mit der Beta hatte ich jetzt schon zwei Mal einen Volumenabsturz (Raid0) an meiner DS212+. Leider habe ich dabei einige Daten verloren :-(
Der SMART Test hat keinen Defekt der Festplatten festgestellt. Ich werde jedenfalls in Zukunft auf eine Betafirmware verzichten.

Du hast aber schon meine Beiträge zur Beta hier gelesen? Dass man immer erst einmal ein Backup machen muss ... von daher kann ich nicht nachvollziehen, dass du Daten verloren hast. Und ganz sicherlich ist der SMART-Test kein Test, um die Güte des Dateisystems oder des LVMs zu beurteilen ... viele Fehler tauchen aber auf diesen Ebenen auf.

Itari

 

[Christian72D]

Zum Glück hat er ja nur das SHR eingesetzt.
Was würde jetzt passieren wenn ich beide Platten ausbaue, eine neue einsetze, auf ihr DSM neu installiere, alles soweit einrichte und dann die zweite (alte) Platte einbaue?
Kann ich dann auf die Daten der zweiten Platte zugreifen?

 

[Benares]

Was braucht soviel CPU wenn der DSM läuft

Mir ist aufgefallen, dass bei offenem DSM die CPU immer so um die 20-30% ausgelastet ist. Das zeigt mir "top", aber auch die CPU-Anzeige im DSM.
Nur, welcher Prozess verbraucht die CPU?

Ich verstehe die "top"-Anzeige bei offenem DSM nicht so ganz

Mem: 126528K used, 909144K free, 0K shrd, 4400K buff, 53972K cached
CPU: [COLOR="#FF0000"]24.8% usr  5.1% sys[/COLOR]  0.0% nic 69.9% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 0.97 0.60 0.70 1/157 1132
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
 9599  9563 root     S    13884  1.3  [COLOR="#FF0000"]0.2[/COLOR] /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
14442  9563 root     S    13616  1.3  [COLOR="#FF0000"]0.2[/COLOR] /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
32429 10284 root     R     5616  0.5  [COLOR="#FF0000"]0.2[/COLOR] top
 9632  9595 nobody   S    99084  9.5  0.0 /usr/syno/apache/bin/httpd -DHAVE_PHP
 9633  9595 nobody   S    99084  9.5  0.0 /usr/syno/apache/bin/httpd -DHAVE_PHP

Die Summe der %CPU-Spalte ergibt bei weitem nicht den angegeben Wert

Bei geschlossenem DSM ist es halbwegs plausibel:

Mem: 116072K used, 919600K free, 0K shrd, 1820K buff, 48716K cached
CPU:  0.3% usr  0.1% sys  0.0% nic 99.4% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 0.32 0.76 0.84 1/152 32653
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
 7875  7868 admin    S    61116  5.9  0.1 /usr/syno/mysql/libexec/mysqld --basedir=/usr/syno/mysql --datadir=/volume1/@database/mysql --user=admin --max_
 7874  7868 admin    S    61116  5.9  0.1 /usr/syno/mysql/libexec/mysqld --basedir=/usr/syno/mysql --datadir=/volume1/@database/mysql --user=admin --max_
 5655     1 root     S     9664  0.9  0.1 /usr/syno/bin/scemd
32429 10284 root     R     5616  0.5  0.1 top
 9632  9595 nobody   S    99084  9.5  0.0 /usr/syno/apache/bin/httpd -DHAVE_PHP
 9633  9595 nobody   S    99084  9.5  0.0 /usr/syno/apache/bin/httpd -DHAVE_PHP
 9634  9595 nobody   S    99084  9.5  0.0 /usr/syno/apache/bin/httpd -DHAVE_PHP
 9595     1 root     S    95552  9.2  0.0 /usr/syno/apache/bin/httpd -DHAVE_PHP

Versteht das jemand?

Gruß Benares

 

[rauppe31]

Dies verursacht die neue Statusanzeige.

 

[Benares]

Hallo rauppe32,

das ist mir klar. Mir ging es eher darum, welcher Prozess das genau ist und warum "top" das nichts anzeigt.

Gruß Benares

 

[rauppe31]

Aha.
Bei mir wird jedenfalls auch nichts angezeigt.

 

[trox]

Hallo zusammen,

hatte bei dem Update meiner DS409+ mit dem neuen DSM ein Problem.

Bei "Aktualisierung der Konfiguration" blieb der Vorgang hängen - der Status war immer gleich weit (0%).

Habe dann die /var/log/messages angeschaut.

Da stand:

Upgrade.cgi: upgrade.cpp(1103) : failed to system cmd=[//upd@te/updater -v / > /dev/null 2>&1], r=35584

Leider wird der Output von updater nach /dev/null geschrieben.
Wollte wissen was der ausgibt, also habe ich den Inhalt des PAT Files auf die Diskstation entpackt, und den Updater manuell gestartet , damit ich einen Konsolen-Output kriege.

Es gab im späten Update-Prozedere einen "Segmentation Fault", das ist also der Grund warum das Update hängen bleibt. Also irgendwie eine Referenz auf einen ungültigen Speicherbereich.

Trotzdem: ich konnte die Diskstation neu staten, und DSM 4.0 scheint installiert worden zu sein. Bin nur nicht sicher ob zu 100% komplett.

Wollte das nur mal berichten...

gruss
troX

 

[king_dingeling]

Ist es schon jemandem aufgefallen, dass die Grösse der DSM-Hintergrundbilder neuerdings nicht mehr dynamisch sind ? Dies war beim 3.2 noch nicht so. Gut ich mag vielleicht mit einem 27"-Bildschirm (2560*1440) aus der Reihe fallen.

 

[rauppe31]

Hallo zusammen,

hatte bei dem Update meiner DS409+ mit dem neuen DSM ein Problem.

Bei "Aktualisierung der Konfiguration" blieb der Vorgang hängen - der Status war immer gleich weit (0%).

Habe dann die /var/log/messages angeschaut.

Da stand:


Leider wird der Output von updater nach /dev/null geschrieben.
Wollte wissen was der ausgibt, also habe ich den Inhalt des PAT Files auf die Diskstation entpackt, und den Updater manuell gestartet , damit ich einen Konsolen-Output kriege.

Es gab im späten Update-Prozedere einen "Segmentation Fault", das ist also der Grund warum das Update hängen bleibt. Also irgendwie eine Referenz auf einen ungültigen Speicherbereich.

Trotzdem: ich konnte die Diskstation neu staten, und DSM 4.0 scheint installiert worden zu sein. Bin nur nicht sicher ob zu 100% komplett.

Wollte das nur mal berichten...

gruss
troX

Das war bei einigen anderen auch der Fall. Steht irgendwo in diesem Monsterthread.
Sollte aber alles installiert sein.

 

[trox]

Seit dem Update auf von DSM 3.2 auf 4.0 habe ich vermehrt solche Meldungen im dmesg-Log:

[ 1706.024457] ata3.00: failed command: READ FPDMA QUEUED
[ 1706.029605] ata3.00: cmd 60/80:00:80:b1:47/00:00:97:00:00/40 tag 0 ncq 65536 in
[ 1706.029609] res 40/00:00:00:fb:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
...
[ 1706.706640] ata3.00: device reported invalid CHS sector 0

Scheint aber nicht an der Hardware zu liegen, sondern eher ein Bug im Kernel zu sein.

Eine sehr ausführliche Diskussion dazu ist hier: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/550559

S.M.A.R.T. Status aller Disks ist normal. Smartctl auf der Console läuft leider nicht, gibt einen Segmentation Fault.

Gruss troX

 

[Fartman]

Ein ähnlich vermehrtes aufkommen von meldungen in der /var/log/messages kann ich seit dem Update auf 4.0b auch beobachten.

->>


Jan 22 15:31:06 torrent_info.cgi: common.cpp:201 Failed to curl perform, postfields={"arguments":{"fields":["id","name","trackerStats"],"ids":[245]},"method":"torrent-get"} , code=7, err=Couldn't connect to server
Jan 22 15:31:07 torrent_info.cgi: common.cpp:201 Failed to curl perform, postfields={"arguments":{"fields":["id","name","trackerStats"],"ids":[245]},"method":"torrent-get"} , code=7, err=Couldn't connect to server
Jan 22 15:31:10 scheduler: taskmgt.c (979) The process [12444] of downloading task(247) is gone. The status now is:2
Jan 22 15:31:10 scheduler: taskmgt.c (989) What happened?
Jan 22 15:31:10 scheduler: taskmgt.c (979) The process [12444] of downloading task(244) is gone. The status now is:8
Jan 22 15:31:10 scheduler: taskmgt.c (989) What happened?
Jan 22 15:31:10 scheduler: taskmgt.c (979) The process [12444] of downloading task(245) is gone. The status now is:8
Jan 22 15:31:10 scheduler: taskmgt.c (989) What happened?
Jan 22 15:31:10 scheduler: taskmgt.c (979) The process [12444] of downloading task(246) is gone. The status now is:8
Jan 22 15:31:10 scheduler: taskmgt.c (989) What happened?
Jan 22 16:29:52 kernel: [ 7296.005784] ------------[ cut here ]------------
Jan 22 16:29:52 kernel: [ 7296.010405] Badness at a01e1170 [verbose debug info unavailable]
Jan 22 16:29:52 kernel: [ 7296.016406] NIP: a01e1170 LR: a01e1864 CTR: a01e7310
Jan 22 16:29:52 kernel: [ 7296.021368] REGS: bf897e60 TRAP: 0700 Tainted: P (2.6.32.12)
Jan 22 16:29:52 kernel: [ 7296.028149] MSR: 00029000 <EE,ME,CE> CR: 24028088 XER: 00000000
Jan 22 16:29:52 kernel: [ 7296.034268] TASK = bf843600[83] 'ata/0' THREAD: bf896000
Jan 22 16:29:52 kernel: [ 7296.039399] GPR00: 00000001 bf897f10 bf843600 bf8e8000 bf8e8080 00000050 00000001 00000001
Jan 22 16:29:52 kernel: [ 7296.047789] GPR08: fffffbc9 a0390000 24002482 00000000 24028088 ed6da99b 1fff2100 00000000
Jan 22 16:29:52 kernel: [ 7296.056176] GPR16: 007fff00 fff90000 00000000 00000001 1fff2288 00800000 ffe00040 bf8e9438
Jan 22 16:29:52 kernel: [ 7296.064566] GPR24: 00000000 00000000 00000050 bf8e8000 a0390000 bf8e8080 00000009 bf8e8080
Jan 22 16:29:52 kernel: [ 7296.073144] NIP [a01e1170] ata_sff_hsm_move+0x4c/0x624
Jan 22 16:29:52 kernel: [ 7296.078279] LR [a01e1864] ata_pio_task+0x11c/0x138
Jan 22 16:29:52 kernel: [ 7296.083064] Call Trace:
Jan 22 16:29:52 kernel: [ 7296.085542] [bf897f10] [00200200] 0x200200 (unreliable)
Jan 22 16:29:52 kernel: [ 7296.090773] [bf897f60] [a01e1864] ata_pio_task+0x11c/0x138
Jan 22 16:29:52 kernel: [ 7296.096265] [bf897f80] [a00441a8] worker_thread+0x104/0x180
Jan 22 16:29:52 kernel: [ 7296.101843] [bf897fc0] [a0047d0c] kthread+0x74/0x78
Jan 22 16:29:52 kernel: [ 7296.106728] [bf897ff0] [a000f07c] kernel_thread+0x4c/0x68
Jan 22 16:29:52 kernel: [ 7296.112124] Instruction dump:
Jan 22 16:29:52 kernel: [ 7296.115089] 7c7b1b78 7cba2b78 80040034 7cd33378 3ae31438 3a400000 70090001 40a20028
Jan 22 16:29:52 kernel: [ 7296.122868] 3d20a039 800989ac 21600000 7c0b0114 <0f000000> 2f800000 41be000c 38000001
Jan 22 16:29:52 scemd: SCEMD: disk 1 wake up from hibernation
Jan 22 16:30:53 kernel: [ 7357.000655] ata2.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
Jan 22 16:30:53 kernel: [ 7357.007736] ata2.00: failed command: READ FPDMA QUEUED
Jan 22 16:30:53 kernel: [ 7357.012899] ata2.00: cmd 60/08:00:00:00:90/00:00:00:00:00/40 tag 0 ncq 4096 in
Jan 22 16:30:53 kernel: [ 7357.012904] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 22 16:30:53 kernel: [ 7357.027542] ata2.00: status: { DRDY }
Jan 22 16:30:54 kernel: [ 7357.516073] ata2.00: device reported invalid CHS sector 0
Jan 22 16:30:55 scemd: SCEMD: disk 2 wake up from hibernation

Seit dem Update auf von DSM 3.2 auf 4.0 habe ich vermehrt solche Meldungen im dmesg-Log:



Scheint aber nicht an der Hardware zu liegen, sondern eher ein Bug im Kernel zu sein.

Eine sehr ausführliche Diskussion dazu ist hier: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/550559

S.M.A.R.T. Status aller Disks ist normal. Smartctl auf der Console läuft leider nicht, gibt einen Segmentation Fault.

Gruss troX

 

[ichel]

Bei mir (Ds211+) geht die Verbindung (beim MAC) übern Finder mit dem AFP Protokoll nicht mehr... auch per SMB lässt sich die Box nicht einbinden ...

 

[oetzi]

Moin moin,

nachdem das mein erster Post hier im Forum ist (bisher war ich nur sehr interessierter Leser) zunächst mal ein herzliches Grüß Gott und jetzt schon mal vielen Dank für die zahlreichen nützlichen Tipps, die ich hier bis jetzt finden konnte.

Sollte das Problem hier schon mal irgendwo diskutiert worden sein muss ich zu meiner Verteidigung sagen: ich habe ca. 1,5 Stunden lang die Suche bemüht und nix passendes gefunden. Zwar diesen Thread, aber da steht auch keine Lösung. :S

Als altes Spielkind musste ich natürlich auch die 4.0 Beta ausprobieren. Draufspielen war kein Problem. Scheint alles funktioniert zu haben. Dann fing allerdings die Thumbnail-Erzeugung neu an. Bei 40.000 Bilder wollte ich das meiner 210j (und meinen Nerven) nicht antun. Also photo-Ordner erst mal umbenannt und einen neuen angelegt.

Dann wollte ich die Fotos mit dem Foto Uploader aus dem DSAssistant neu hochladen. Das funktionierte eine Weile auch recht gut. Mittlerweile ist es aber regelmäßig so, dass die Verbindung zur DiskStation beim Upload abbricht. Mit dem DSM 3.2 hatte ich das Problem nie.



Die Weboberfläche der PhotoStation und des DSM kann ich nach einer solchen Meldung ohne Probleme erreichen. Abhilfe für den Foto Uploader schafft dann nur, wenn ich den Client-Rechner und die DiskStation neu starten. Kann dann aber durchaus sein, dass das Problem sofort (oder nach einigen Hundert Bildern) erneut auftritt.

Nen Bug bei Synology habe ich schon aufgemacht (Bug-ID #4059). Mal sehen, was die dazu sagen.

Hier noch ein paar technische Details:
- DiskStation 210j mit DSM 4.0 Beta
- Aktueller DSAssistant (kann grad net die genaue Version sagen, da ich nicht daheim bin. Ist aber vor ca. 1 Woche runtergeladen worden)
- Gigabit-Netzwerk (JUMBO-Frame ist sowohl auf der DS, als auch auf dem Client deaktiviert)
- Client-Rechner: Windows 7 64Bit mit 12GB Ram
- Rechner ist mit der DS über eine FritzBox 6360 verbunden

Zu dem Thema /var/log/messages:
Mir ist auch aufgefallen, dass da jetzt wesentlich mehr drin steht als noch mit der 3.2er-DSM-Version. Ich war davon ausgegangen, dass sie vielleicht einfach das Log-Level in der Beta etwas hochgedreht haben. Na ja, da will ich ihnen mal net den Kopf abreißen. Immerhin ist es im Moment noch offiziell ne Beta. Da erwarte ich noch nicht, dass alles funktioniert.

 

[joku]

Ist es schon jemandem aufgefallen, dass die Grösse der DSM-Hintergrundbilder neuerdings nicht mehr dynamisch sind ? Dies war beim 3.2 noch nicht so. Gut ich mag vielleicht mit einem 27"-Bildschirm (2560*1440) aus der Reihe fallen.

Ich hab nur einen 22" und eingestellt 1680x1050, das sieht alles gut aus

 

[BigBlue007]

Ich habe dieselben Probleme wie trox und Fartman. Ich habe meine DS erst seit ein paar Tagen, bzw. eigentlich schon die zweite. Ich hatte erst die DS212j, bei der ich aber schnell merkte, dass mir die Performance nicht reicht. Bin dann auf eine DS411+ umgestiegen. Die Platten sind zwei identische WD25EZRX. Ich habe auf beiden DSen von Anfang an die DSM 4 - Beta genutzt. Da ich die 212j nur kurz in Betrieb hatte, könnte ich jetzt nicht mit Sicherheit sagen, ob es das Problem dort auch schon gab. Bei der 411+ ist es mir aber sofort aufgefallen, dass das Hochfahren aus dem Hibernation ewig dauert. Im Log sehe ich dann dieselben Meldungen wie ihr, wobei es sich auch abwechselt; mal betrifft es die eine, mal die andere Platte. Insofern würde ich einen HW-Defekt ebenfalls ausschließen wollen.

Da mir halt leider der Vergleich zum Betrieb mit DSM 3.2 fehlt, würde ich jetzt mal ein Downgrade auf DSM 3.2 machen und testen wollen, wie es sich da verhält. Weiß zufällig jemand, ob ein Downgrade analog zu dieser Anleitung von 4.0 auf 3.2 möglich sein sollte?