TS-809 "hängt" sich auf bei Dateicopy um die 17GB

Erstmal meine Hardware:

TS-809 Pro
Firmware Version 3.1.0 build 0627T
8 x Seagate Barracuda ES.2 1000GB, 32MB Cache, SATA II (ST31000340NS), Firmware SN16
Formatiert im RAID 5 mit ext4 Filesystem

Problem ist nun, das sich die Kiste "aufhängt" wenn ich Dateien in der Größenordnung ~17GB und größer auf das NAS kopiere. Es gibt keine
scharfe Grenze. Er schafft auch mal 23GB zu kopieren. Aber ich kann den Fehler jederzeit reproduzieren. Spätestens bei der 2. Datei war
es das dann.

Die Files, die ich nach etlichen Versuchen geschafft habe, wieder zurück zu kopieren, scheint kein Problem zu sein.

Wobei sich die Kiste nicht komplett aufhängt. Zum Beispiel ist die Adminoberfläche noch komplett erreichbar, allerdings sind die Shares
nicht mehr sichtbar. Auch scheinen die ganzen Dienste noch verfügbar zu sein, nur wenn auf die Platten zugegriffen werden soll,
klappt das dann nicht (Webserver läuft zwar, aber es wird nichts geliefert).

Anmeldung per SSH und/oder Telnet geht bis zur Passwortabfrage, dann bleibt das Terminal hängen (vermutlich will er da irgendwo
zugreifen, wo er jetzt nicht dran kommt).

Ist man angemeldet per SSH/Telnet, kann man sich zwar auf der Flash Partition bewegen, aber sobald man auf die Platten zugreifen will (/share/MD0_DATA)
bleibt die Session hängen.

Ein Reboot klappt auch nicht, im Display steht zwar Rebooting, aber weiter passiert nichts. Nur ein hartes Ausschalten hilft.

Er selber scheint noch auf die Platten zuzugreifen, denn sowohl die grünen LED blinken, als auch die Plattenzugriffe sind zu hören.

In den Systemprotokollen ist keinerlei Eintrag zu finden. Auch in den Logs unterhalb von /var habe ich nichts finden können.

Bin für jeden Tipp dankbar.

Noch habe ich keinen Support eingeschaltet, wollte erst mal hören, ob das Problem möglicherweise vor dem NAS sitzt

Die Platten sind alle in Ordnung. Alle SMART Werte im grünen Bereich, nichts auffälliges im Log. Die Platten hatte ich vorher
Problemlos an meinem Adaptec RAID Controller im Rechner gehabt für einige Wochen. Auch dort liefen die Unauffällig.

Das Problem tritt wie gesagt auch nur bei großen Dateien auf. Ich hatte schon gute 4TB an Daten auf das NAS geschaufelt
gehabt. Keinerlei Probleme, bis ich halt einige Dicke Brocken zu kopieren hatte.

Es ist also kein Problem 20 Dateien von jeweils 10GB zu kopieren. Nur wenn ich 10 Dateien zu 20GB kopieren wollte, bleibt
das System spätestens bei der 2. Datei hängen (reproduzierbar).

Sofern hier niemand zufällig einen Tipp hat, werde ich erst noch mal das NAS platt machen und Neu aufsetzen. Sollte der
Fehler dann bleiben, werde ich mal den QNAP Support einschalten.

Kleines Update (falls es jemand interessieren sollte ).

Es sieht also so aus, als ob es nicht an der Dateigröße hängt, denn jetzt ist es auch passiert, nachdem ich gerade viele kleine Dateien (so um die 3-7MB) kopieren wollte.

Ich habe mittlerweile auch den Support eingeschaltet, aber die brauchen immer einige Tage bis zur Antwort. Denen habe ich mittlerweile Zugriff auf die Kiste
gewährt. Die Kiste ist gestern wieder hängen geblieben. Diesmal lasse ich die Kiste in dem Zustand, vielleicht findet der Support was.

Ich hatte zwischendurch auch mal die Kiste komplett platt gemacht, nochmal die Firmware drüber gebügelt und alles von Hand neu eingerichtet. Einzig was mir aufgefallen
ist, dass in der Webgui der Füllstand des Shares genau 2TB angezeigt wird, obwohl es etwas über 3,5TB sind, was in der Gesamtanzeige beim RAID auch richtig angezeigt
wird.

Ich habe da nie drauf geachtet, aber sind die HD LEDs (die grünen) eigentlich immer an, oder aus wenn kein Zugriff statt findet. Beim Zugriff blinken die ja, aber ich
habe noch nie darauf geachtet, wenn nichts los ist. Denn derzeit leuchten alle 8 LEDs dauerhaft.

Wenn ich etwas neues weiß, werde ich berichten. Ich warte jetzt auch eine Rückmeldung des Supports.

Das sich alle 8 Platten gleichzeitig aufhängen?

Mehr als sehr unwahrscheinlich. Es ist ja nicht so, dass eine Platte aus dem Verbund fliegt. Sondern es sieht vielmehr
danach aus, als ob der SATA Controller seine Arbeit einstellt.

Wobei ich den Zusammenhang nicht wirklich erkennen kann. Es passiert nämlich nur beim Kopiervorgang. Ansonsten ist
die Kiste ja 24h am Tag am laufen.

Ich hatte es mehrfach geschafft, den Fehler mit den großen Dateien zu reproduzieren, und dachte "aha, das ist es also".

Dann hatte ich den Support eingeschaltet, der war auf der Kiste drauf, und der Fehler tauchte nicht mehr auf. Auf nachfrage,
ob irgend etwas umkonfiguriert wurde, habe ich leider keinerlei Antwort erhalten. Hatte aber auch darauf hingewiesen,
das ich die Kiste nochmals komplett platt mache, und neu Aufsetze.

Das war dann am letzten Wochenende. Dann habe ich angefangen, meine Daten zu kopieren. Das ging auch so 3,5TB gut, inkl.
der dicken Brummer. Ich dachte schon, das jetzt alles OK ist, und ich ggf. beim ersten Mal was falsch gemacht habe.

Und dann wollte ich noch meine Musik auf die Kiste kopieren (halt alles kleine MP3 Files). Und schon beim 3. oder 4. Album
(Also recht wenigen Dateien) blieb die Kiste wieder hängen.

Leider ist der Support recht träge. Heute wurde mal wieder eine Conf Datei angefordert. Vermutlich werde ich vor Montag
nichts mehr von denen hören. Und ich kann die Kiste derzeit nicht nutzen, was mich nicht unbedingt freudig stimmt...

Ich habe ein RAID5 gebildet, über alle Platten.

Wenn wirklich eine Platte austeigen sollte, dann dürften trotzdem nicht alle anderen Platten im selben Moment still gelegt werden. Ich kann die Platten ja noch nicht mal von der Shell über Low-Level Kommandos ansprechen, vom Filesystem, etc. ganz abgesehen.

Das eine Platte kaputt gehen kann, OK. Dafür kauft man sich so ein Teil. Das muß so ein Teil abkönnen (besonders in der Preisklasse).

Wenn mir an einem billig Board eine Platte zicken macht, dann mag vielleicht sogar mal der Controller hängen bleiben, aber das konnte man im Logfile sehen.

Und gerade in einem RAID5 darf ja eine Platte dauerhaft ausfallen. Ich kann eine Platte einfach mitten drin raus ziehen. Es wird zwar langsamer dann (weil alles on the fly berechnet werden muß), aber es läuft weiter. Dazu ist doch das RAID gedacht, genau für diesen Fall. Es fällt z.B. nachts dauerhaft eine Platte aus. Aber das stört nicht weiter, ausser das die Performance etwas runter geht.

Und eine solche Macke würde man im Logfile sehen können.

Abgesehen davon, hatte ich diese Platten vorher einige Wochen an einem anderen RAID Controller am laufen, und das ohne Probleme (und es waren genau die selben Daten, die ja jetzt auf das QNAP ausgelagert werden sollen).

Und wenn eine Platte rumzickt, dann würde irgendwann auch mal ein Alert ausgelöst werden. Aber hier passiert das nicht. Es bleibt einfach auf einmal hängen. Und es ist bisher nicht ein einziger Plattenfehler aufzeigt worden.

Das sieht eher danach aus, dass sich die SATA Controller oder irgend etwas noch davor (vielleicht der Expander?) einfach aufhängt.

Was buggy Firmware angeht, so nenne mir irgend einen Plattenhersteller, der in den letzten Jahren nicht negativ da aufgefallen ist (Es gibt keinen, egal ob WD, Samsung, Hitachi/IBM oder Seagate, etc.)

Es ist halt komisch, das nirgendwo ein Logfile Eintrag vorkommt, der auf irgend etwas hinweist.

Entweder ist das QNAP Teil defekt (was ja auch sein kann), oder irgend eine Macke in der QNAP Firmware schlägt da zu.

Nun ja, ich denke mal, nächste Woche wird sich der Support mal wieder melden. Ich berichte dann...

Zitat von "X5_492_Neo"

alle 8 Platten in einem Raid 5?????? Oha! :shock: :shock:

Wieso "oha"? Warum sollte ich da splitten? Einzige Änderunge würde mal sein, das ich auf ein RAID6 gehen werde, wenn ich Richtung 14TB gehe, also 2TB Platten einsetze.

Übrigens fällt mir noch etwas ein. Im Fehlerfall kann ich die Kiste auch nicht mehr rebooten (egal ob per Webinterface, oder init auf der Shell), es geht nicht. Er bleibt mit einer "Rebooting" Meldung im Display stehen, und macht einfach weiter. Da hilft nur hartes Power-Off.

Du meinst sicherlich den bekannten Hinweis von Robin Harris. Da ging es aber nicht um die Anzahl der Festplatten, sondern der größe des Filesystem und der erwarteten Fehlerhäufigkeit.

Das Problem ist dann, das ab einer bestimmten größe es Statistisch gesehen zu mindestens einem nicht wiederherstellbaren Fehler kommt, und eine ausgefallene Platte nicht restauriert werden könnte, weil es beim rebuild immer (statistisch gesehen) zu einem Fehler kommen würde.

Aber das hat nichts mit der Menge der Platten zu tun. Das ist mittlerweile bei den großen Platten ein grundsätzliches Problem. Daher wurde ja auch RAID 6 eingeführt. Allerdings wird damit das Problem nur ein wenig verschoben.

Ich habe den Artikel wieder gefunden (google sei Dank http://blogs.zdnet.com/storage/?p=162

Zumindest in den lesbaren Logfiles (einiges wird ja in eine DB geschrieben, oder dann eben auch nicht ) ist kein Ansatzpunkt zu finden.

Selbst auf der Console wird nichts in dem Moment nichts ausgegeben. Es wird zwar gemeckert, wenn ich ein LAN Kabel ziehe,
aber wenn Plattentechnisch nix mehr läuft, bleibt die Kiste stumm :-/

Wenn wirklich eine Platte spinnen würde, dann müsste ich in den letzten 14 Tagen mindestens mal einen Alarm, irgend eine entsprechende
Änderung in den S-M.A.R.T. Werten oder ein sonstiges Fehlverhalten feststellen müssen.

Temperaturfehler hatte ich auch schon mal im Verdacht. Aber das letzte Mal blieb die Kiste hängen, als es schön kühl war.

Und der Support wirkt auch irgendwie Ratlos.

yoshi666,

Hast Du schon einen Support Call eröffnet?

Wenn nicht, dann wäre es gut, wenn Du das noch machen würdest. Damit QNAP sieht, dass das kein "Einzelschicksal" ist.

Ich habe nämlich langsam das Gefühl, dass die einen überhaupt nicht ernst nehmen, abgesehen von der Tatsache, dass die
sich für eine Antwort immer 3 Tage Zeit nehmen

Ich bin gerade dabei, es zu bereuen diesen Dreck gekauft zu haben

Zitat von "christian"

würdest du mich zu dem Thema bitte auch via PN auf dem laufenden halten? Danke

Ja klar, sobald sich der Support mal erniedrigt und mir Antwortet, damit ich dann wieder irgend eine Datei denen zusenden kann, um dann
wieder 3 Tage auf die nächste Antwort zu bekommen, werde ich die Infos hier rein schreiben.