- Mitglied seit
- 26. Jun 2010
- Beiträge
- 158
- Punkte für Reaktionen
- 2
- Punkte
- 22
Hi,
ich habe gestern über die integrierte Backupfunktion meinen ganzen /photo Ordner inklusive Photo Station von meiner DS110j auf meine neue DS411slim transferiert. Beide Systeme sind mit der aktuellen DSM 3.2 Beta ausgestattet. Das funktionierte eigentlich auch relativ problemlos, alle Miniaturansichten wurden übernommen und die Photo Station funktionierte auf Anhieb. Nur der Index-Daemon durchsuchte nochmals alles, fand nichts neues und hörte heute dann endlich auf.
Dafür fing synomkthumbd plötzlich an sehr viel Leistung zu ziehen. Laut Webinterface waren 31 Fotos in der Warteschlange. Tja, nur tat sich dabei nichts. Es startete auch kein convert Prozess. Pausieren und Fortzsetzen brachte genauso wenig, wie den synomkthumbd Dienst über die Konsole zu beenden und erneut zu starten. DS neu starten brachte auch keinen Erfolg.
Ich machte mich dann mit strace auf die Fehlersuche. Dabei fand ich heraus, dass der Prozess alle photo Verzeichnisse (inkl. der @eadir's) durchgeht - ganz normal bis dahin. Allerdings mehr als 110.000 stat-Aufrufe in der Minute - alle nur vom photo Ordner! Mit diesem Tempo wäre es in unter 5 Minuten mit allem fertig. Aber er wiederholte es immer wieder, das konnte man leicht beobachten.
Gut, nach einem Blick in die /var/spool/thumb_create.queue.tmp war ich noch nicht viel schlauer, außer dass da einige Ordner (keine Dateien) drinnen standen, die er tatsächlich durchsuchte. Danach hatte ich den synomkthumbd Dienst nochmals angehalten, die eben erwähnte Datei umbenannt und den Dienst wieder gestartet. Nun war Schluss mit dem Durchsuchen. Nach einer Korrektur der Werte in /var/spool/conv_progress_photo (total=0) wurde auf in der DSM Oberfläche wieder angezeigt, dass zur Zeit keine Miniaturansichten mehr erstellt werden. Sieg auf der ganzen Linie
Da ich diesem Verhalten aber nicht traute, schob ich ein paar neue Fotos in die Verzeichnisse. Doch siehe da, der convert Prozess sprang sofort an und nach einigen Sekunden/Minuten der erfolgreichen Konvertierung beendete er sich auch wieder. synomkthumbd lief nicht wieder Amok.
Ich hoffe, dass es bei diesem Verhalten nun bleibt und, dass ich mir damit nichts zerstört habe. Aber die Thumbs existieren sowieso schon alle, sollte also kein Problem sein?
Abschließend, würde ich von euch gerne wissen, ob ihr so ein oder ähnliches Problem schon einmal hattet. Hängt es vielleicht doch mit der Beta Version zusammen? Soll ich mich trotzdem einmal an Synology wenden? Nur warum tritt es dann rein beim Wiederherstellen vom Backup auf?
Und sollte die Datei /var/spool/thumb_create.queue.tmp normalerweise nicht nur ohne dem .tmp existieren? Habe ich meine DS irgendwann vielleicht ungünstig abgemurkst, dass dieser "Rest" zurückblieb und alles blockierte? Über eventuelle Erfahrungswerte zu den Dateien in /var/spool im Bezug auf die Miniaturansichten würde ich mich sehr freuen. Natürlich auch über alle anderen Tipps.
Falls jemand das gleiche Problem hat und für die vermutliche Lösung weitere Anleitungen braucht, bitte einfach kurz melden.
MfG Christian
ich habe gestern über die integrierte Backupfunktion meinen ganzen /photo Ordner inklusive Photo Station von meiner DS110j auf meine neue DS411slim transferiert. Beide Systeme sind mit der aktuellen DSM 3.2 Beta ausgestattet. Das funktionierte eigentlich auch relativ problemlos, alle Miniaturansichten wurden übernommen und die Photo Station funktionierte auf Anhieb. Nur der Index-Daemon durchsuchte nochmals alles, fand nichts neues und hörte heute dann endlich auf.
Dafür fing synomkthumbd plötzlich an sehr viel Leistung zu ziehen. Laut Webinterface waren 31 Fotos in der Warteschlange. Tja, nur tat sich dabei nichts. Es startete auch kein convert Prozess. Pausieren und Fortzsetzen brachte genauso wenig, wie den synomkthumbd Dienst über die Konsole zu beenden und erneut zu starten. DS neu starten brachte auch keinen Erfolg.
Ich machte mich dann mit strace auf die Fehlersuche. Dabei fand ich heraus, dass der Prozess alle photo Verzeichnisse (inkl. der @eadir's) durchgeht - ganz normal bis dahin. Allerdings mehr als 110.000 stat-Aufrufe in der Minute - alle nur vom photo Ordner! Mit diesem Tempo wäre es in unter 5 Minuten mit allem fertig. Aber er wiederholte es immer wieder, das konnte man leicht beobachten.
Gut, nach einem Blick in die /var/spool/thumb_create.queue.tmp war ich noch nicht viel schlauer, außer dass da einige Ordner (keine Dateien) drinnen standen, die er tatsächlich durchsuchte. Danach hatte ich den synomkthumbd Dienst nochmals angehalten, die eben erwähnte Datei umbenannt und den Dienst wieder gestartet. Nun war Schluss mit dem Durchsuchen. Nach einer Korrektur der Werte in /var/spool/conv_progress_photo (total=0) wurde auf in der DSM Oberfläche wieder angezeigt, dass zur Zeit keine Miniaturansichten mehr erstellt werden. Sieg auf der ganzen Linie
Da ich diesem Verhalten aber nicht traute, schob ich ein paar neue Fotos in die Verzeichnisse. Doch siehe da, der convert Prozess sprang sofort an und nach einigen Sekunden/Minuten der erfolgreichen Konvertierung beendete er sich auch wieder. synomkthumbd lief nicht wieder Amok.
Ich hoffe, dass es bei diesem Verhalten nun bleibt und, dass ich mir damit nichts zerstört habe. Aber die Thumbs existieren sowieso schon alle, sollte also kein Problem sein?
Abschließend, würde ich von euch gerne wissen, ob ihr so ein oder ähnliches Problem schon einmal hattet. Hängt es vielleicht doch mit der Beta Version zusammen? Soll ich mich trotzdem einmal an Synology wenden? Nur warum tritt es dann rein beim Wiederherstellen vom Backup auf?
Und sollte die Datei /var/spool/thumb_create.queue.tmp normalerweise nicht nur ohne dem .tmp existieren? Habe ich meine DS irgendwann vielleicht ungünstig abgemurkst, dass dieser "Rest" zurückblieb und alles blockierte? Über eventuelle Erfahrungswerte zu den Dateien in /var/spool im Bezug auf die Miniaturansichten würde ich mich sehr freuen. Natürlich auch über alle anderen Tipps.
Falls jemand das gleiche Problem hat und für die vermutliche Lösung weitere Anleitungen braucht, bitte einfach kurz melden.
MfG Christian
