Wechsel zwischen obersten Verzeichnissen sehr langsam/massig log-Einträge beim Syncen

[Claus67]

Hallo,
ich habe neuerdings 2 Probleme beim Zugriff auf meine DS210j unter XP die sich wie folgt äußern:

1) Beim Wechsel zwischen obersten gemappen Verzeichnissen friert der Explorer ein dabei fängt das NAS wild an auf den Festplatten zu rödeln. Abhängig von der Anzahl der Dateien/Verzeichisse/Größe im Unterverzeichnisbaum kann das bis zu 45sec dauern, bis man anschließend verzögerungsfrei in die Unterverzeichnisse klicken kann. Verlässt man den Verzeichnisbaum und kehr später wieder zurück, geschieht das geleiche erneut. Im Detail genügt es schon mit der linken Maustaste das Verzeichnis anzuklicken, dass das NAS losrödelt.

2) Im Rahmen der Fehleranalyse bin ich noch darauf gestossen, dass das Sync-Tool "Allway Sync" neuerdings bei manchen Verzeichnissen (z.B."secuirty" auf dem NAS) mitten in der Verzeichnisanalyse oder dem Syncen plötzlich für ~40sec bis Minuten anhält und dadurch erheblich länger braucht als früher ohne dass sich der Datenumfang oder Inhalt geändert hat. Zudem sind neuerdings tausende log-Eintäge in messages der Form:

Jul 23 15:54:52 smbd: index_findex_add.c:310 Failed to open /volume1/@eaDir/security/SYNO@file_index_queue (No such file or directory).
Jul 23 15:54:53 smbd: index_findex_add.c:310 Failed to open /volume1/@eaDir/security/SYNO@file_index_queue (No such file or directory).
Jul 23 15:54:54 smbd: index_findex_add.c:310 Failed to open /volume1/@eaDir/security/SYNO@file_index_queue (No such file or directory).

zu finden. Das Verzeichnis /volume1/@eaDir/ entält nur:

drwxrwxrwx  3 root root 4096 Jul 21 22:56 .
drwxr-xr-x 21 root root 4096 Jul 21 22:56 ..
drwxrwxrwx  2 root root 4096 Jul 22 23:06 photo

Das geht dann so weit, dass ein neuer Sync-Vorgang angestoßen wird bevor der vorangegangene abgeschlossen ist...
Da wir das NAS als unsere zentrale papierlose Ablage (Korespondenz, Fotos, Musik, ...) nutzen machen diese Phenomene die Nutzung praktisch unmöglich...

Das Problem 2), insbesondere die Einträge in messages sind sicher nach dem Update auf DSM 3.1-1748 aufgetreten, den ich erst vor ein paar Tagen durchgeführt habe. Beim Problem 1) bin ich mir nicht mehr ganz so sicher, ob dies schon vor dem Update so extrem war, zumindest hatte ich den Eindruck dass es seit 2-3 Wochen beim Verzeichniswechsel etwas länger dauert. So massiv aber d.h. bis zu 45sec ist mir erst nach dem Update bei speziellen Verzeichnissen aufgefallen. Vielleicht habe ich aber erst im Rahmen der Analyse nun erst die wirklich kritischen Verzeichnisse gefunden.

In wie weit 2) mit 1) zusammenhängt möchte ich den Experten überlassen...

Hier nun noch ein paar Details zur Konfiguration und was ich bisher ausprobiert habe:

Aktiviert ist der Windows Dateidienst

Gemeinsame Freigaben:
"security" (verschlüssel)
"homes"
und weitere...

"security" hat auf dem NAS die Struktur:

security/claus/Verzeichnis1/Unterverzeichnis1/usw.
security/claus/Verzeichnis2/Unterverzeichnis1/usw.
usw.

Auf XP-Seite ist auf "claus" gemapped d.h. sichtbar im Explorer als:
S:/Verzeichnis1/Unterverzeichnis1/usw.
S:/Verzeichnis2/Unterverzeichnis1/usw.
usw.

Das Problem 1) tritt auf, wenn ich die Ebene Verzeichnis1, Verzeichnis2, usw. anklicke.
Nicht aber, wenn ich zwischen Verzeichnisx und zugeörigem Unterverzeichnisy wechsele.
Da gleiche gilt auch in "homes"!!!

Folgendes habe ich bereits versucht:

- Verzeichniswechsel über Dateibrowser oder Files Station des DSM ist praktisch verzögerungsfrei.
- Virenscanner Avast deaktiviert: keine Auswirkung
- Firewall deaktiviert: keine Auswirkung
- Alle Programme deinstalliert die sich in das Maus-Menü (sichtbar nach anklicken der Verzeichnis mit der rechten Maustaste) eingeklinkt haben bis auf Avast und IZArc (Packer), die ich seit mehr als 1 Jahr ohne Probleme Nutze und in den letzen Wochen auch keinen Programupdate erfuhren: Keine Auswirkung
- keine Einräge in der log-Datei messages, die im Zusammenhang mit den Verzeichniswechseln stehen.

Hier bin ich nun mit meinen Latein am Ende und hoffe, dass Ihr mir weiterhelfen könnten...

Danke & Gruß

Claus

 

[Matthieu]

Ist ein relativ komplexes Problem, eine genaue Anleitung kann ich da auch nicht geben. Und denke daran: Letzter Schritt ist der Synology-Support - wenn das Problem bekannt ist bekommst du auch (nur) dort eine Version in der das Problem behoben ist.
Als Anregung kann ich aber die verschiedenen Optionen des SMB-Dienstes der DS geben: Datenbank optimieren etc. Ich weiß nicht genau ob SMB auch auf den Index-Dienst der DS zurückgreift, aber du könntest testweise diesen Dienst einschalten: Unter "Gemeinsame Ordner"->"Bearbeiten" nach "Datei neu ordnen" suchen und aktivieren.
Ist die DS vielleicht mit etwas anderem beschäftigt wenn der Erstzugriff so lange dauert?

MfG Matthieu

 

[Claus67]

File-Index-Datenbank für verschlüsselte Shares wird nicht (korrekt) erzeugt.

Danke Matthieu für die Anregung sich die verschiedenen Optionen des SMB-Dienstes/"Datei neu ordnen" näher anzusehen und ich glaube die Ursache für das Problem 2 d.h. die langen Wartezeiten/Fehlermeldungen beim Syncen mit "Allway Sync" gefunden zu haben, wobei das wohl nur die Spitze des Eisberges ist...

In Kürze:
Es scheint sich für alle verschlüsselten Shares kein File-Index-Datenbank korrekt anlegen zu lassen. Der DSM glaubt aber, dass eine File-Index-Datenbank da ist und versucht daraufhin,wohl mit timeout, darauf zuzugreifen und wirft daraufhin Fehlermeldungen in "messages" aus.

Die Frage, die sich stellt:
Wie kann man alternativ die Erstellung der File-Index-Datenbank zB. auf der Kommandozeite (da es ja nicht übder den DSM geht) erzeugen.

Folgendes habe ich im Detail herausgefunden:

1. Für die verschlüsselte Share "security" war "Datei-Neuordnung aktivieren" bereits aktiviert (...muss länger zurückliegen und muss ich irgendwie verdrängt haben...).
   
2. Ein Druck auf den Button "Neu ordnen" lieferte sofort "0 Dateien und 0 Ordner wurden indexiert" und der Button ist ausgegraut. Das ist widersprücklich, da tausenden Dateien und hunderte von Verzeichnissen enthalten sind.
   
3. Daraufhin habe ich versucht "Datei-Neuordnung aktivieren" zu deaktivieren. Nach dem Klick auf "OK" erscheint die Fehlermedung "Das Passwort ist ungültig (2480)".
   Es scheint sich dabei um das Passwort der File-Index-Datenbank zu handeln wie "messages" zeigt:
   

   Jul 28 18:09:52 shareman.cgi: sqlite.c (105) Failed to connect to (null), user: (null), pass:xxx, db:/volume1/@eaDir/security/SYNO@.fileindexdb. (unable to open database file)
   Jul 28 18:09:52 shareman.cgi: shareman.cpp:2091 Fail to get the indexing status
   Jul 28 18:10:02 shareman.cgi: sqlite.c (105) Failed to connect to (null), user: (null), pass:xxx, db:/volume1/@eaDir/security/SYNO@.fileindexdb. (unable to open database file)
   Jul 28 18:10:02 shareman.cgi: shareman.cpp:2091 Fail to get the indexing status
   Jul 28 18:10:13 shareman.cgi: sqlite.c (105) Failed to connect to (null), user: (null), pass:xxx, db:/volume1/@eaDir/security/SYNO@.fileindexdb. (unable to open database file)
   Jul 28 18:10:13 shareman.cgi: shareman.cpp:2091 Fail to get the indexing status
   Jul 28 18:10:18 shareman.cgi: sqlite.c (105) Failed to connect to (null), user: (null), pass:xxx, db:/volume1/@eaDir/security/SYNO@.fileindexdb. (unable to open database file)
   Jul 28 18:10:18 shareman.cgi: shareman.cpp:2091 Fail to get the indexing status
   Jul 28 18:10:23 shareman.cgi: sqlite.c (105) Failed to connect to (null), user: (null), pass:xxx, db:/volume1/@eaDir/security/SYNO@.fileindexdb. (unable to open database file)
   Jul 28 18:10:23 shareman.cgi: shareman.cpp:2091 Fail to get the indexing status

4. Ein Blick ins Verzeichnis "/volume1/@eaDir/", wo die File-Index-Datenbanken in gleichnamigen Verzeichnissen abgelegt sind zeigt, dass die Verzeichnis & Datenbank für "security" fehlt. (Die anderen ließen sich im Rahmen der Fehleranalyse über den DSM "Datei ordnen" angelegt.)
   

   drwxrwxrwx  6 root root 4096 Jul 24 20:49 .
   drwxr-xr-x 23 root root 4096 Jul 24 23:16 ..
   drwxrwxrwx  2 root root 4096 Jul 24 15:51 backups
   drwxrwxrwx  2 root root 4096 Jul 28 14:03 homes
   drwxrwxrwx  2 root root 4096 Jul 28 17:33 photo
   drwxrwxrwx  2 root root 4096 Jul 28 12:00 test
   
   ./backups:
   total 104
   drwxrwxrwx 2 root root  4096 Jul 24 15:51 .
   drwxrwxrwx 6 root root  4096 Jul 24 20:49 ..
   -rwxrwxrwx 1 root root 92160 Jul 24 15:51 SYNO@.fileindexdb
   
   ./homes:
   total 37392
   drwxrwxrwx 2 root root     4096 Jul 28 14:03 .
   drwxrwxrwx 6 root root     4096 Jul 24 20:49 ..
   -rwxrwxrwx 1 root root 38234112 Jul 28 14:03 SYNO@.fileindexdb
   
   ./photo:
   total 16284
   drwxrwxrwx 2 root root     4096 Jul 28 17:33 .
   drwxrwxrwx 6 root root     4096 Jul 24 20:49 ..
   -rwxrwxrwx 1 root root 16646144 Jul 28 17:33 SYNO@.fileindexdb
   
   ./test:
   total 28
   drwxrwxrwx 2 root root  4096 Jul 28 12:00 .
   drwxrwxrwx 6 root root  4096 Jul 24 20:49 ..
   -rwxrwxrwx 1 root root 15360 Jul 28 12:00 SYNO@.fileindexdb
   -rwxr-xr-x 1 root root     3 Jul 28 12:00 SYNO@file_index_queue

5. Nach etwas probieren habe ich dann festgestellt, dass sich für die verschlüsselte Share "security" "Datei-Neuordnung aktivieren" nur dann deaktivieren läßt, wenn die Share getrennt (geschlossenes Sicherheitsschloss im Bedienfeld - Gemeinsame Ordner) ist. Das Gleiche gilt dann auch wieder für das aktivieren ... oder das Ändern der "Beschreibung" der Share...
   
6. Ist die "Datei-Neuordnung" von "security" deaktiviert, klappt es dann auch wieder verzögerungsfrei mit dem Syncen mittels "Allway Sync". D.h. das beschriebene Problem 2 verschwindet.
   
7. Da mich dies Verhalten überrascht hat, habe ich eine weitere verschlüsselte Share "test" angelegt und den Inhalt von "scurity" auf der Kommandozeile mit cp rüberkopiert. Für diese lies sich dann problemlos bei eingehängter Share (geöffnetes Sicherheitsschloss) "Datei-Neuordnung aktivieren" selektieren oder die "Beschreibung" der Share ändern.
   
8. ABER: Für "test" ist der Button "Neu ordnen" ausgegraut, neben dem sofort und nicht erst nach dem Drücken der Schaltfläche steht "0 Dateien und 0 Unterodner wurden indexiert". Diese ist mit ca 15kB sehr klein, wenn man die Anzahl der Dateien und Verzeichnisse in "backups" sieht. (siehe oben). Erst wenn man "SYNO@file_index_queue" unbenennt ist die Schaltfläche nicht mehr ausgegraut. Der Klick auf "Neu ordnen" liefert dann aber in messages wieder:
   

   Jul 28 20:01:08 shareman.cgi: sqlite.c (105) Failed to connect to (null), user: (null), pass:xxx, db:/volume1/@eaDir/test/SYNO@.fileindexdb. (unable to open database file)
   Jul 28 20:01:08 shareman.cgi: shareman.cpp:2091 Fail to get the indexing status

   Es scheint hier ein generelles Problem mit dem "Datei ordnen" und verschlüsselten Shares vorzuliegen!!!

Fazit:
Über das deselektieren von "Datei-Neuordnung aktivieren" verschwinden das Probleme 2: "lange Wartezeiten/Fehlermeldungen beim Synce mittels "Allway Sync"", wobei ich dies nunmehr nur noch als Symptom sehe. Das eigentliche Problem scheint zu sein, dass die File-Index-Tabelle für verschlüsselte Shares fehlt bzw. mittels DSM nicht korrekt angelegt werden kann.
Der nächste Schritt bei der Problemlösung wäre für mich diese wieder sauber anzulegen und dann zu sehen, wie diese sich nach erneutem Klick auf "Neu ordnen" verhält und dies mit Problem 1:"Lange Wartezeit bei Erstzugriff" zusammenhängt....

Irgendjemand eine Idee wie sich die File-Index-Tabelle (z.B. auf der Kommandozeile) anlegen lässt.

Danke & Gruß

Claus

PS: Zur Frage,ob der DSM beim Erstzugriff mit etwas anderem beschäftigt ist folgendes: top auf der Kommandozeile als root ausgeführt zeigt, dass nichts anderes beim Erstzugriff nebenher läuft. Nur eben "smbd -D" mit ~20% CPU-Last, der nächste Prozess mit < 1%.

 

[Matthieu]

Da das Problem einwandfrei reproduzierbar ist, würde ich dir doch ans Herz legen den Support zu kontaktieren. Ein Workaround der Community bringt wenig, wenn das Problem dauerhaft in der Firmware bleibt. Wunder mich fast, dass es noch niemandem aufgefallen ist. Vielen Danke auf jeden Fall für diese lange Suche nach der Ursache; ich denke da wird Synology auch nicht groß rumraten sondern direkt die Entwickler ran lassen wenn du ihnen das schreibst was du hier hast. Wenn du es nicht übersetzen möchtest, kannst du das Support-Formular auch auf Deutsch verwenden (obwohl es dort anders steht).
http://www.synology.com/support/support_form.php?lang=deu

MfG Matthieu