TS-439 afp/smb Verzeichnisaufbau (teils) unglaublich langsam

    Liebe QNAP-Club-Mitglieder,


    leider konnte man mir im „offiziellen“ Forum keine wirklich brauchbare Auskunft geben. Mit scheint es hier symphatischer zu sein.


    Situation: Ich habe seit rund einem Jahr ein TS-439 Turbo Nas Pro im Einsatz. Das Ganze ist via Gigabit-Erthernet mit meinem MacPro verbunden, darin laufen 2x WD 1TB Platten im RAID0 und weitere 2x WD 1,5TB Platten ebenfalls im RAID0, alle 7200RPM und ext4 formatiert.


    Problem: Wenn ich durch meinen Musikordner „browse“ (viele Ordner, Unterordner und Dateien) hab ich immer wieder das Problem, dass der Verzeichnisaufbau komplett stoppt und sich Dateien nur mit großer Verzögerung aufrufen lassen (zwischen 30 Sekunden und 2 Minuten). Das Problem äußert sich sowohl via SMB als auch via AFP und ich habe es auf zwei Rechnern getestet mit OS X, Windows 7 und Windows XP. Die CPU-Last bleibt bei diesen „Fehlerfällen“ übrigens niedrig. Es gibt natürlich einige Leistungspeaks wenn ich schnell zwischen den Verzeichnissen herumspringe, die „Hänger“ werden so aber nicht sichtbar.


    Ich bin etwas ratlos, ist das Verhalten normal? Guter Rat wäre teuer, danke für eure Hilfe. Wenn ihr noch Informationen braucht, lasst es mich wissen.


    Liebe Grüße,
    Alex


    Update: Dazu sagen sollte ich, dass das auch passiert wenn ich bereits in einem der Unterordner bin der vielleicht nur 10 Dateien beinhaltet. Das NAS wird nach solchen Aussetzern dann allgemein langsam, die CPU- und Speicherlast bleibt aber konstant niedrig. Wenn ich im Musikordner einen solchen Aussetzer „provoziere“ in dem ich einfach ein paar mal das Verzeichnis wechsle, reagieren übrigens auch alle anderen Shares extrem langsam. Dann kann es schon einmal ein paar Minuten dauern bis ich wieder ein Verzeichnis angezeigt bekomme.

    Hi Alex,


    danke und willkommen im Club ;)


    Habt Ihr da im Englischen Forum schon irgendwie etwas getestet oder können wir noch einmal von vorne anfangen?
    Das wäre halt einfacher aber auch eventuell etwas aufwendiger, weil ich dann mal ein paar Sachen Testen lassen würde. (Um den Problem auf die schliche zu kommen).
    Weil normal ist das eigentlich nicht.


    Grüsse, David

    Ja, es kommt immer drauf an... Es kann auch durchaus immer mal länger dauern. ;) z.B. schwinge ich mich gleich noch einmal Weg. :D


    Gehe mal via SSH auf das NAS:
    http://forum.qnapclub.de/viewtopic.php?f=80&t=8700#p48809 (Screencast)


    dann führe mal:


    Code
    fdisk -l


    und

    Code
    mount


    aus.


    Weil bei den 2 RAID's schauen wa erst einmal, wie die gemounted sind ;)


    Die Ausgabe kannst Du dann hier in einem Code Block posten.


    Grüsse, David

    Naja, das ist klar,... trotzdem super!


    fdisk -l gibt folgendes zurück

    Code
    Disk /dev/sdx: 128 MB, 128057344 bytes8 heads, 32 sectors/track, 977 cylindersUnits = cylinders of 256 * 512 = 131072 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdx1               1           8        1008   83  Linux/dev/sdx2               9         440       55296   83  Linux/dev/sdx3             441         872       55296   83  Linux/dev/sdx4             873         977       13440    5  Extended/dev/sdx5             873         913        5232   83  Linux/dev/sdx6             914         977        8176   83  LinuxDisk /dev/sda: 1000.2 GB, 1000204886016 bytes255 heads, 63 sectors/track, 121601 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sda1   *           1          66      530113+  83  Linux/dev/sda2              67         132      530145   82  Linux swap / Solaris/dev/sda3             133      121538   975193695   83  Linux/dev/sda4          121539      121600      498015   83  LinuxDisk /dev/sda4: 469 MB, 469893120 bytes2 heads, 4 sectors/track, 114720 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/sda4 doesn't contain a valid partition tableDisk /dev/sdb: 1000.2 GB, 1000204886016 bytes255 heads, 63 sectors/track, 121601 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdb1   *           1          66      530113+  83  Linux/dev/sdb2              67         132      530145   82  Linux swap / Solaris/dev/sdb3             133      121538   975193695   83  Linux/dev/sdb4          121539      121600      498015   83  LinuxDisk /dev/sdc: 1500.3 GB, 1500301910016 bytes255 heads, 63 sectors/track, 182401 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdc1   *           1          66      530113+  83  Linux/dev/sdc2              67         132      530145   82  Linux swap / Solaris/dev/sdc3             133      182338  1463569695   83  Linux/dev/sdc4          182339      182400      498015   83  LinuxDisk /dev/sdd: 1500.3 GB, 1500301910016 bytes255 heads, 63 sectors/track, 182401 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdd1   *           1          66      530113+  83  Linux/dev/sdd2              67         132      530145   82  Linux swap / Solaris/dev/sdd3             133      182338  1463569695   83  Linux/dev/sdd4          182339      182400      498015   83  LinuxDisk /dev/md9: 542 MB, 542769152 bytes2 heads, 4 sectors/track, 132512 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/md9 doesn't contain a valid partition tableDisk /dev/md4: 542 MB, 542769152 bytes2 heads, 4 sectors/track, 132512 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/md4 doesn't contain a valid partition tableDisk /dev/md0: 998.5 GB, 998598246400 bytes2 heads, 4 sectors/track, 243798400 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/md0 doesn't contain a valid partition tableDisk /dev/md1: 1498.6 GB, 1498695270400 bytes2 heads, 4 sectors/track, 365892400 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/md1 doesn't contain a valid partition tableDisk /dev/sdv: 500.1 GB, 500107862016 bytes255 heads, 63 sectors/track, 60801 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdv1               1       60800   488375968+  83  LinuxDisk /dev/sds: 500.1 GB, 500107862016 bytes255 heads, 63 sectors/track, 60801 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sds1               1       60801   488384001   83  Linux[/] # clear[/] # fdisk -lDisk /dev/sdx: 128 MB, 128057344 bytes8 heads, 32 sectors/track, 977 cylindersUnits = cylinders of 256 * 512 = 131072 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdx1               1           8        1008   83  Linux/dev/sdx2               9         440       55296   83  Linux/dev/sdx3             441         872       55296   83  Linux/dev/sdx4             873         977       13440    5  Extended/dev/sdx5             873         913        5232   83  Linux/dev/sdx6             914         977        8176   83  LinuxDisk /dev/sda: 1000.2 GB, 1000204886016 bytes255 heads, 63 sectors/track, 121601 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sda1   *           1          66      530113+  83  Linux/dev/sda2              67         132      530145   82  Linux swap / Solaris/dev/sda3             133      121538   975193695   83  Linux/dev/sda4          121539      121600      498015   83  LinuxDisk /dev/sda4: 469 MB, 469893120 bytes2 heads, 4 sectors/track, 114720 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/sda4 doesn't contain a valid partition tableDisk /dev/sdb: 1000.2 GB, 1000204886016 bytes255 heads, 63 sectors/track, 121601 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdb1   *           1          66      530113+  83  Linux/dev/sdb2              67         132      530145   82  Linux swap / Solaris/dev/sdb3             133      121538   975193695   83  Linux/dev/sdb4          121539      121600      498015   83  LinuxDisk /dev/sdc: 1500.3 GB, 1500301910016 bytes255 heads, 63 sectors/track, 182401 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdc1   *           1          66      530113+  83  Linux/dev/sdc2              67         132      530145   82  Linux swap / Solaris/dev/sdc3             133      182338  1463569695   83  Linux/dev/sdc4          182339      182400      498015   83  LinuxDisk /dev/sdd: 1500.3 GB, 1500301910016 bytes255 heads, 63 sectors/track, 182401 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdd1   *           1          66      530113+  83  Linux/dev/sdd2              67         132      530145   82  Linux swap / Solaris/dev/sdd3             133      182338  1463569695   83  Linux/dev/sdd4          182339      182400      498015   83  LinuxDisk /dev/md9: 542 MB, 542769152 bytes2 heads, 4 sectors/track, 132512 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/md9 doesn't contain a valid partition tableDisk /dev/md4: 542 MB, 542769152 bytes2 heads, 4 sectors/track, 132512 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/md4 doesn't contain a valid partition tableDisk /dev/md0: 998.5 GB, 998598246400 bytes2 heads, 4 sectors/track, 243798400 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/md0 doesn't contain a valid partition tableDisk /dev/md1: 1498.6 GB, 1498695270400 bytes2 heads, 4 sectors/track, 365892400 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/md1 doesn't contain a valid partition tableDisk /dev/sdv: 500.1 GB, 500107862016 bytes255 heads, 63 sectors/track, 60801 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdv1               1       60800   488375968+  83  LinuxDisk /dev/sds: 500.1 GB, 500107862016 bytes255 heads, 63 sectors/track, 60801 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sds1               1       60801   488384001   83  Linux


    mount gibt folgendes zurück


    Liebe Grüße,
    Alex

    Hi,


    so bin wieder da ;)
    Also MD0 und MD1 sehe ich da raus.
    Dann testen wir mal erst die "I/O Performance".


    Code
    dd if=/dev/zero of=/share/MD0_DATA/test.img bs=1G count=1 oflag=direct


    Code
    dd if=/dev/zero of=/share/MD1_DATA/test.img bs=1G count=1 oflag=direct


    Nutzt Du eigentlich ext3, ext4 mit oder ohne write cache?
    Ich weiss halt nicht genau ob ich heute Abend noch zum Antworten komme. Ab morgen dürfte es etwas flüssiger laufen ;)


    Grüsse, David

    Hi,


    ganz egal, ich bin schon mal sehr sehr froh, dass du mir dankenswerter weise hilfst!


    Der Command funktioniert bei mir in der Form nicht. Ich bekomme die „Usage“ zurück.


    Code
    BusyBox v1.01 (2010.11.09-16:38+0000) multi-call binaryUsage: dd [if=FILE] [of=FILE] [bs=N] [count=N] [skip=N]	  [seek=N] [conv=notrunc|noerror|sync]Copy a file, converting and formatting according to options	if=FILE		read from FILE instead of stdin	of=FILE		write to FILE instead of stdout	bs=N		read and write N bytes at a time	count=N		copy only N input blocks	skip=N		skip N input blocks	seek=N		skip N output blocks	conv=notrunc	don't truncate output file	conv=noerror	continue after read errors	conv=sync	pad blocks with zerosNumbers may be suffixed by c (x1), w (x2), b (x512), kD (x1000), k (x1024),MD (x1000000), M (x1048576), GD (x1000000000) or G (x1073741824).


    http://www.gnu.org/software/co…l_node/dd-invocation.html diese Seite sagt über den oflag=direct Parameter folgendes:

    Zitat

    oflag=direct
    Use direct I/O for data, avoiding the buffer cache. Note that the kernel may impose restrictions on read or write buffer sizes. For example, with an ext4 destination file system and a linux-based kernel, using ‘oflag=direct’ will cause writes to fail with EINVAL if the output buffer size is not a multiple of 512.


    Write Cache für ext4 ist aktiviert.


    Ohne oflag bekomme ich folgendes Ergebnis (lustiger Weise ohne die Daten über den Writespeed):

    Code
    1+0 records in
1+0 records out


    Wobei es bei MD1_DATA ziemlich lang gedauert hat, ohne, dass die Festplatten hörbar aktiv gewesen wären.


    Irgendwas stimmt da nicht, oder?


    Grüße,
    Alex


    UPDATE: Hab den write-cache jetzt einmal deaktiviert, konnte das Problem aber trotzdem reproduzieren.
    UPDATE2: Ich beginne schonmal die Daten am aktuellsten stand auf externe Platten zu spielen,... ;)

    Hi,


    das iss nix schlimmes. Ich schreibe halt immer so wie es unter Linux funktioniert. Die Kommandos auf dem NAS sind z.Z. etwas "geschmälert". Das iss aber net schlimm, weil man die umschreiben kann.


    Machen wir daraus mal was anderes. ;)


    Code
    if=/dev/zero of=/share/MD0_DATA/test.img bs=1024k count=1024


    Code
    if=/dev/zero of=/share/MD1_DATA/test.img bs=1024k count=1024


    so sollte es funktionieren.
    Danach halt wieder die test.img daten löschen:

    Code
    rm /share/MD0_DATA/test.img


    Code
    rm /share/MD1_DATA/test.img


    Mal schauen dabei raus kommt. ;)


    Grüsse, David


    axo: Das aber erst machen, wenn Du mit dem Kopieren auf den externen Fertig bist. und 1x mit und ohne write cache.

    Komisch, den write-speed zeigt er mir trotzdem nicht an.


    Habs auf verschiedenen Wegen probiert:

    Code
    time dd if=/dev/zero of=/share/MD0_DATA/test.img bs=500M count=2


    Code
    time dd if=/dev/zero of=/share/MD0_DATA/test.img bs=1024k count=1024


    Bin gerade am überlegen die Kiste komplett abzuschießen und mit ext3 neu zu formatieren. Macht das Sinn oder ist es wahrscheinlich, dass ich dann das Selbe Problem in Grün habe, wenns einen anderen Grund hat?


    Danke nochmal.


    Grüße,
    Alex

    Mache Dir mal nicht zu viel Arbeit.


    Wenn Du nachher etwas zeit hättest (so ab 19 Uhr), könnte ich auch mal mit dem Teamviewer drauf schauen.
    In der Subkategorie MAC hat auch einer das Problem mit den langamen Verzeichnissaufbau. Eventuell liegt es nur an etwas kleinem.


    Das ergebnis posten wir dann für die Mitleser hier ;)


    Grüsse, David

    Heute Abend bin ich blöderweise weg, jetzt am Nachmittag hätt ich bis 17:00 Zeit. Morgen, erst wieder gegen Abend, allerdings möchte ich auf keinen Fall, dass du Sonntagabend mit meinen Problemen verbringst.


    Ja, wäre absolut hilfreich, hab zu dem Thema NIX gefunden, die Dokumentation würd dabei natürlich ich übernehmen.


    Update: Weiterer Terminvorschlag, Montags (jederzeit) wie es dir passt.

    Hallo zusammen,


    ich möchte mich in dieses Thema einklinken, da ich ein das gleiche Problem habe. Ich habe in den letzten Tagen das Forum durchforstet um hierfür eine Lösung zu finden, hab aber nichts anderes gefunden.


    Hier kurz meine Problembeschreibung:
    Ich habe seit letzter Woche das TS-239 Pro II in Betrieb. Die Festplatten laufen im Raid0 und sind mit ext4 formatiert. die Firmware ist die "3.3.6 Build 1110T".
    Ich habe meine gesamte iTunes Mediathek in den Ordner "Multimedia" von meiner bisherigen ext. Festplatte kopiert. Die Verzeichnisstruktur wird von iTunes verwaltet.
    Die Datenbank ist recht umfangreich (ca. 7500 Interpreten-Ordner in der ersten Ebene). Die Netzwerkverbindung zwischen Rechner (iMac) und NAS läuft über 1GBit-Netz und war beim kopieren auch flott.
    Wenn ich jedoch von meinem iMac über AFP oder SMB auf den Inhalt meiner Mediathek zugreifen möchte dauert es mehrere Minuten bis die Verzeichnisebene mit den Interpreten geöffnet wird. Bei der nächsten Ebene dauert es dann wieder so lange.
    Rufe ich die Verzeichnisstruktur über den "Web File Manager" auf, geht das öffnen der Verzeichnisse recht zügig (ca. 2-3 Sek).
    Ich habe auch schon testweise alle Dienste außer AFP im NAS abgeschaltet, aber leider ohne Verbesserung.
    Ich habe auf gleicher Ebene neben meinem iTunes Verzeichnis auch noch andere Verzeichnisse (mit ca. 50 Unterverzeichnissen). Hier ist der Verzeichnisaufbau sehr schnell.
    Das Problem tritt also nur bei der großen Anzahl an Verzeichnissen auf.


    Werden beim Aufruf über AFP/SMB erst alle Verzeichnisse in einen Zwischenspeicher geladen bevor sie angezeigt werden? Wenn ja, wie läßt sich das ggf. abschalten?


    Ich bin sicherlich nicht der einzige, der die Verzeichnisstruktur durch iTunes erledigen läßt.
    Was mache ich also falsch bzw. was muss ich ändern.


    Gruß
    Thomas

    Hallo zusammen,


    ich kann mich meinem Vorredner nur anschließen. Fast die gleiche Konfiguration und ebenfalls das Problem des langsamen Verzeichnisaufbaus.
    Leider hat die Suche im Netz und im Forum noch kein Ergebnis gebracht.


    Für Hilfe oder Tipps wäre ich sehr sehr dankbar.
    Grüße

    Hallo ihr beiden,


    tut mir leid, dass ich mit "etwas" Verzögerung antworte.


    Auch wir konnten das Problem damals nicht lösen – trotz der tollen Hilfe von Terz. Auch wenn die Platte mittlerweile ext3 formatiert ist und nicht mehr im RAID1 läuft – das Problem ist das selbe: Lahmer Verzeichnisaufbau bei Musiksammlungen oder vergleichbaren Strukturen. Beim nächsten NAS-Kauf muss ich besser darauf achten. Laut den Views hier und im offiziellen Forum, scheinen wir mit dem Problem bei weitem nicht alleine zu sein.


    Grüße,
    Alex

    Hallo Zusammen,


    gibt es hierauf bereits eine Lösung ? Ich habe auch ziemlich viele Verzeichnisse, die sind zwar schon nach Anfangsbuchstabe in extra Verzeichnissen sortiert aber dennoch dauert es ca. 5-10sek. wenn ich ein Ordner mit 20 Verzeichnissen öffne. Via AFP als auch via SMB :|


    Grüße
    Stefan