Timeout beim Verzeichnis anlegen

    Hallo zusammen,
    ich habe folgendes Problem mit meinem TS410 (Firmware 3.6.0, aber auch frühere Versionen haben dieses Problem):
    Ich betreibe das NAS ausschließlich als externe Festplatte für meinen W7-64Ultimate-PC, es ist absolut nichts von all den anderen Möglichkeiten, die das Ding so leisten kann aktiviert.
    Eingebaut sind 2 Festplatten mit 1 TB und 2 mit 1.5 TB. Die Festplatten sind EXT3 formaitert, und das Ganze läuft als RAID5 seit 2 Jahren problemlos.
    Seit 2 Monaten passiert jedoch immer wieder folgendes:
    Beim Erzeugen eines neuen Verzeichnisses kommt es zu Timeouts. Dabei spielt es keine Rolle, wie oder womit ein neues Verzeichnis erzeugt wird.
    Normalerweise kopiere ich komplette Verzeichnisbäume mit dem TotalCommander auf das Laufwerk. Das Problem tritt jedoch auch auf, wenn ich Verzeichnisse mit dem FreeCommander oder Explorer erstelle. Selbst wenn ich mich mit PUTTY einlogge, und ein 'makdir' aufrufe, kommt es zu diesem Problem.
    Was nach wie vor problemlos geht, ist folgendes: Ich kann beliebig große und auch beliebig viele Dateien in ein existierendes Verzeichnis kopieren.
    Wenn jedoch beim Kopieren eines Verzeichnisbaumes ein neues Verzeichnis auf dem NAS angelegt werden muss, rappelt die Kiste wie verrückt los, und nach 2 Minuten kommt ein Fehlermeldung, dass das Verzeichnis nicht angelegt werden konnte.
    Je nach 'Zustand' des NAS kann das Anlegen eines neuen Verzeichnisses sehr schnell gehen, es kann einige Sekunden dauern, oder 2 Minuten, und wenn es kanz schlimm kommt, rebootet das NAS. Dann mit der Fehlermeldung, dass das Filesystem nicht 'clean' ist. Woran ich erst einmal nicht glaube, ich vernute hier eher, dass noch ein Eintrag im Journal des EXT3 steht.
    Ein CheckDisk (über die grafische Oberfläche gestartet) meldet keine Probleme, und nach einem manuell ausgelöstem Reboot ist das Filesystem auch wieder 'clean'.


    Den 'Zustand' kann ich beeinflussen. Die ersten 2 Jahre war der Zustand 'gut', ich hatte überhaupt keine Probleme.
    Wenn ich Verzeichnisbäume auf das NAS-Laufwerk kopiere, kann es sein, dass die ersten Verzeichnisse noch recht flott angelegt werden können. Ich lasse dazu die Netzwerk-Anzeige im Taskmanager mitlaufen. Aber dann treten immer dann Lücken in der Datenübertragung auf, wenn ein neues Verzeichnis angelegt werden muss.
    Ich habe mir zum Testen ein Verzeichnisbaum zusammengestellt, in dem sich 10 Unterverzeichnisse befinden. In jedem dieser Unterverzeichnisse befinden sich weitere 10 Unterverzeichnisse. Und in jedem dieser Unter-Unterverzeichnisse befinden sich 500 Dateien mit jeweils 2 Byte. Nicht, dass sich hier sinnvolle Daten drin befinden, aber mit dem Verzeichnis habe ich schon einmal bei einem anderen NAS-Laufwerk (ncht von QNAP) Fehler gefunden.
    Ein solchen Verzeichnis lag noch auf dem NAS-Laufwerk. Wenn ich dieses Verzeichnis jetzt auf dem NAS-Laufwerk lösche, und danach gleich wieder hinaufkopiere, ist die Summe aller Verzeichnisse und Dateien identisch mit dem Stand vorher. Was wohl anders ist, ist die Anordnung innerhalb der Festplatten. Auch sehen die einzelnen Einträge in den einzelnen Verzeichnissen wohl anders aus.
    Das Interessante ist jedenfalls, dass ich nach so einem Löschen und wieder hinaufkopieren wieder einige andere Verzeichnisbäume auf das NAS kopieren kann. Aber der Fehler ist damit nicht behoben, sondern nur verschoben, denn das Problem ist immer noch das selbe.


    Da alle Lese-Operationen absolut problemlos funktionieren, und auch das Schreiben von Dateien problemlos funktioniert, möchte ich die Festplatten (alle SMART-Werte zeigen OK an) eigentlich als Ursache ausschließen.
    Wenn eine Datei auf das NAS-Laufwerk geschrieben wird, wird ja nicht nur die Datei geschrieben, sondern auch das Verzeichnis, in dem sich die Datei bedindet, wird verändert. Das bereitet keine Probleme.
    Nur das Erstellen eines neuen Verzeichnisses dauert manchmal so lange, dass es zu Timeouts kommt.


    Meine Vermutung ist folgende: Das, was sich auf dem NAS befindet, hat sich dort im Laufe von 2 Jahren angesammelt, und ist 'irgendwie' strukturiert oder fragmentiert.
    Wenn ich ein neues Verzeichnis anlegen will, findet irgend eine Form von 'Restrukturierung' des Filesystems statt, für die das TS410 etwas stark 'untermotorisiert' ist. Das Festplattengerappel von 2 bis 3 Minuten zeigt ja, dass hier etwas stattfindet.
    Der 'Zustand' verschlimmert sich mit jedem weiteren erzeugten Verzeichnis, das Anlegen eines Verzeichnisses dauert immer länger, und irgendwann rebootet das NAS dann.


    Durch den QNAP-Support bin ich zwar an die Firmware 3.6.0 gekommen, aber das Problem ist das gleiche.


    Kennt jemand diesen Effekt, und was kann man dagegen tun?


    mfg
    Manni_S

    Hallo Manni,


    ich kann diesen Effekt auf der exakt identischen Plattform (TS-410) und dem Einsatz von Ext3 nachvollziehen. Ab einen bestimmten Füllgrad und gleichzeitigen hohen Level an Verzeichnis und Dateianzahl hatte ich mit dem Erzeugen neuer Ordner nach und nach Probleme inkl. den Timeouts obwohl er dann final den Ordner doch anlegte, bis zu einem Level wo dann definitiv kein Ordner mehr anlegbar war und er rebootete. Der Effekt muss irgendwas mit der Anzahl von Verzeichnissen zu tun haben, da man sobald man wieder einige Ordner löschte, exakt soviele neu anlegen konnte. Dubios kam mir dabei nur die Anzahl vor! Wir reden hier von ~450 Ordnern (kaskadiert) was ja keine typische begrenzende "IT Zahl" darstellt. Ich hab mir dann insofern beholfen, dass ich zusätzliche Freigabe erzeugt habe und darin die Ordner zu ungefähr gleichen Teilen aufteilte und damit das Problem deeskalierte. Es scheint hier also eine Begrenzung der maximalen Anzahl von Ordnern pro Freigabe unter Ext3 zu geben. Auf meinem zweiten TS-410 was ich alternativ mit Ext4 aufsetzte kann ich diesen Effekt nicht nachvollziehen, da haben ich in einer Freigabe > 700 kaskadierende Ordner bei gleichem Füllgrad und kann problemlos neue Ordner anlegen. Eventuell ist Ext4 dahingehend optimiert.

    Hallo Matrixer,
    schön, dass ich mit meinen Problemen nicht so ganz alleine bin...
    Vielleicht noch einige ergänzende Infos: Ich habe auf dem NAS insgesamt ca. 40.000 Verzeichnisse mit ca. 1,5 Millionen Dateien, das NAS ist ca. 90% voll.
    Allerdings ist eine Sache bei mir anders: Wenn ich mein Test-Verzeichnis mit den 550 Unterverzeichnissen und 50.000 Dateien lösche und wieder hinaufkopiere, habe ich ja wieder die gleiche Anzahl von Dateien und Verzeichnissen wie vorher. Ich kann aber anschließend etliche neue Verzeichnisse anlegen (vielleicht ~100), also mehr als ich vorher gelöscht habe.
    Eine Limitierung gibt es hier laut QNAP nicht, und EXT3 läßt pro Verzeichnis 31998 Unterverzeichnisse zu. Und das gilt für jedes Unterverzeichnis wieder!
    Durch das Löschen und erneut wieder raufkopieren bleibt die absolute Anzahl ja identisch, aber ich kann dann erst einmal ne Zeitlang weitermachen.
    Ich vermute die Ursache irgendwie in der Richtung extrem asymetrisch gewordener H-Bäume (auch wenn ich nicht genau weiss was das ist). Ab einer gewissen Asymetrie, die durch das 2-jährige Arbeiten entstanden ist (immer wieder mal was löschen und neu hinaufkopieren), versucht das Filesystem wohl, die Directories 'umzustruktorieren'...
    Meine Idee geht dahin, dass es vielleicht ein 'Umstrukturierungsprogramm' gibt, welches ähnlich einem Defragmentierungs-Tool arbeitet. Soll es doch ruhin einige Stunden arbeiten, wenn ich danach wieder arbeiten kann. Das Löschen und wieder hinaufkopieren der 110 Verzeichnisse und 50.000 Dateien 'heilt' das NAS-Laufwerk ja schließlich auch, wenn auch nur für kurze Zeit.

    Macht es hier ggf. Sinn mal:


    e2fsck -fD /dev/md0 auszuführen, da das Filesystem dir_indexed ist?

    Hallo,


    ich habe exakt die selben Probleme.
    Von jetzt auf gleich, nachdem mein TS-412 ca ein Jahr funktionierte, habe ich Probleme beim Erstellen von Verzeichnissen. (Exakt wie von manni_S beschrieben)
    Daraus resultiert auch ab und an mal ein :
    "[RAID5 Disk Volume: Drive 1 2 3 4] The file system is not clean. It is suggested that you run "check disk"."
    Verbaut sind 4x2TB Seagate ST2000DL003-9VT1CC32 HD im Raid 5 mit ext3.
    Mir ist bekannt, dass diese HD mittlerweile von Qnap nicht mehr empfohlen werden...
    Hatte die HDs allerdings schon verbaut, als diese noch als unbedenklich eingestuft waren. :-/


    Aktuell hab ich noch 1,2 TB freinen Speicher zur Verfügung.
    Check Disk meldet jedes Mal : Alles OK!!!
    Ordner sind jede Menge auf dem NAS.
    Fehler tritt sowohl mit der Firmware im Auslieferungszustand (3.4.2 schlagmichtot), die ich ein Jahr benutzt habe,
    als auch mit der aktuellen Firmware auf.


    Für Lösungsvorschläge wäre ich wirklich dankbar!!!


    Grüße Kai

    Hallo Kai,
    willkommen im Club! Leider existiert der Support bei QNAP so gut wie nicht...
    Von QNAP kamen leider nur so geistreiche Hinweise wie 'Warten Sie mal die nächste Software-Version ab, vielleicht ist das Problem damit ja schon behoben'...


    Ich vermute das Problem nicht bei den Festplatten, sondern bei der Anzahl der sogenannten 'inodes' des Filesystems (siehe http://www.linupedia.org/opensuse/Inode, hier ist der Satz
    'Sind in einem Filesystem keine Inode mehr frei, können keine Dateien mehr angelegt werden, auch wenn das Filesystem noch längst nicht voll ist. Dieses Problem könnte mit einigen Filesystemtypen in einem Filesystem mit sehr vielen sehr kleinen Dateien auftreten, wenn nicht schon bei der Erstellung des Filesystems extra eine hohe Anzahl von Inodes in Form von Optionen angegeben wurde. Bei einem ext2/ext3 Filesystem kann man das bytes-per-inode ratio mittels der Opition -i von mkfs.ext2 bestimmen.' der entscheidende Hinweis... )


    Die Tatsache, dass das Löschen von etlichen Verzeichnissen dazu führt, dass ich danach dann wieder etliche Verzeichnisse anlegen konnte, bekräftigt meine Vermutung.


    Ich bin das Problem letztendlich dadurch losgeworden, dass ich alle Festplatten durch größere ersetzt habe (macht bei den momentanen Preisen echt Spaß). Nach dem Austausch einer Festplatte wurde das RAID-System dann jeweils auf die neue Platte erweitert. Nachdem dann alle 4 Platten so umgestellt sind, ist noch einmal ein weiterer Durchlauf mit knapp 20 Stunden erforderlich, danach war ich die Probleme los.


    Das 'Bytes-per-inode-ratio' habe ich nicht mehr bestimmt, ich bin auf diesen Artikel erst gestoßen, als ich schon mit der Umstellung begonnen hatte. Nun bin ich auch nicht gerade ein Linux-Experte....
    Was diesem Problem wohl beileibe rücken könnte, wäre ein Programm, welches diese inode-trees umstrukturiert.


    Halt mich auf jeden Fall auf dem Laufenden, wie Du mit dem Problem zurecht gekommen bist. Ich glaube nämlich noch nicht daran, dass ich da Problem für immer los bin...


    mgh
    Manni_S

    Hallo Manni_S,


    vielen Dank für deine Antwort und deine Denkanstöße!
    Die Idee mit den Inodes ist nicht schlecht, wobei sich mir die Frage stellt, warum ich in ein bestehendes Verzeichniss
    ohne Probleme eine große Anzahl von Dateien schreiben kann? Sollte dies dann nicht die selben Probleme verursachen?


    Werde auf jeden Fall mal versuchen Ordner zu löschen und versuchen dann neue zu erstellen.


    Umstieg auf größere Platten kommt bei den aktuellen Preisen nicht in Frage!
    Auch da stellt sich mir die Frage, warum dadurch das Problem behoben ist.
    Gehen wir mal davon aus, dass es sich wirklich mit den Inodes zu tun hat. Entscheidend ist dann wohl das "bytes-per-inode ratio".
    Wenn das so ist, tut mir leid wenn ich es sagen muss, aber ich denke das weißt du auch, hast du das Problem nur hinausgezögert.
    Solltest du deinen Nas weiter füttern und ungefähr die gleiche Anzahl von Ordnern pro Speicher erstellen wie bisher, wirst du wohl in absehbarer
    Zeit wieder an diesem Punkt angekommen sein..
    Ich drück dir alle zur Verfügung stehenden Daumen, dass es nicht so ist!


    Ich werde weiter recherchieren und bescheid geben wenn ich etwas herausfinden sollte.



    Grüße, Kai.

    Hallo,


    ich habe das gleiche Problem mit einer QNAP TS-119 (3.6.1 Build 0302T) und einer 2TB SAMSUNG HD203WI, ext3, 114.86 GB von 1832.31 GB frei.


    Zur Eingrenzung des Problems: wenn ich per SSH im Stammverzeichnis einen Ordner erzeuge geht das sofort und schnell. Wenn ich dann in ein Verzeichnis innerhalb einer Samba-Freigabe unter /share/HDA_DATA gehe und wiederum einen Ordner mit mkdir erzeuge dauert das ca. 1 Minute, ein zweiter Ordner dann nur noch ca. 1 Sekunde.


    Ich vermute also ein Problem mit Samba oder den Berechtigungen, leider bin ich da kein Profi in dem Bereich. Eine größere Platte ist im Anmarsch, aber das wird das Problem eben nur rausschieben...


    vg /Jens.