Beiträge von medikit

3.3.2 Build 0819T, EXT4, RAID5, Write Cache. Ohne Write Cache stürzt es auch ab. Meinst Du, mit EXT3 wäre das nicht passiert?
Ich habe die Leistung beider Dateisysteme verglichen. Mit 802.3ad LACP steht's beim Kopieren großer Dateien (>100 MB) etwa 75 zu 55 für EXT4. Beim Kopieren kleinerer Dateien (< 20 MB) etwa 50 zu 30 für EXT4.

Ich hab's geschafft. Nach nicht mal einer Woche kann ich es reproduzierbar abschießen. Wie's geht? Ich versuche mit dem Mircoschuft-Tool "synctoy" einen Ordner vom PC auf das NAS zu synchronisieren. Synctoy prüft erst lokal, ob sich was geändert hat und dann die NAS-Freigabe und entscheidet dann, was zu tun ist, je nach Vorgabe. Beim Prüfen der NAS-Ordner bleibt synctoy dann plötzlich hängen und nach etwa zwei Minuten verabschiedet sich das QNAP dann mit einen reboot. Spitze.

Ich würd' ja auch brennend gerne ein Ergebnis von

hparm -i

bzw.

hdparm -I

bekommen, aber es gibt nur die oben genannte Fehlermeldung.

Die Standbykommandos funktionieren:

[~] # hdparm -y /dev/sdf
/dev/sdf:
 issuing standby command
 setting standby immediately.


[~] # hdparm -S 0 /dev/sdf
/dev/sdf:
 setting standby to 0 (off)

-b, -B, -c, -d, , -h, -i, -I, -m, -M, -Q, funktionieren nicht, die Optionen, die "DANGEROUS" sind, habe ich nicht ausprobiert

Die ganze "hdparm -?" Liste von a bis z.

Was soll an 100% Auslastung falsch sein? Das ist auch nicht schlimm, denn wozu hat man eine CPU, wenn man sie nicht auslasten will. Du kannst ja mit Putty/ssh auf das NAS gehen und Dir mit dem Befehl "top" die Auslastung in Echtzeit anzeigen lassen.

Zitat von "WinBug"

... genau so ...

Fein, aber sag' mal wie genau so. So im Detail.

Wenn ich eine HDD aus 'nem RAID5 Verbund ziehe, gibt's eine Fehlermeldung im Display "HDD x ejected" und die Status LED am NAS blinkt rot, die grüne HDD LED der gezogenen Platte erlischt. Nach dem Zurückschieben wird man mit einer Blinkorgie an allen HDD belohnt (quasi das Ambilight) und die rote Status LED geht aus.

Im Log steht "Drive X pulled out", "Drive X removed" und "RAID in degraded mode". Anschließend "Drive 8 plugged in", "Drive X added into volume x", "RAID5 Disk Volume: Drive 1 2 3 4 5 6 7 8 Start rebuilding" und später "Rebuilding completed".

Welches Laufwerk ausgefallen ist, kann man an den LEDs bei dieser Methode sehen: die LED erlischt im entsprechenden Einschub.

An sowas beißen sich auch Profis die Zähne aus. Active Failover, Systemspiegelung, Transaktionkontrolle, sichern offener Datenbankdateien, sichern gesperrter Dateien, vollautomatische Übernahme, Lastverteilung auf zwei identische Systeme. Wenn man sowas z.B. von IBM für Serversysteme will, dann braucht man unter sechsstelligen Eurobeträgen garnicht ankommen. Ich will damit sagen, das diese Anforderungen SEHR ambitioniert sind. Für eine low-budget-Lösung aller Anforderungen würden Dir sicher viele Menschen die Füsse küssen.

Ich hab's auch probiert, leider arbeiten meine verbauten Platten unvollständig mit hdparm zusammen.

[~] # hdparm -I /dev/sdf
/dev/sdf:
 HDIO_DRIVE_CMD(identify) failed: Invalid argument

Einige andere funktionieren, z.B. Anzeige der Plattengeometrie. Das Webinterface sagt "ATA Standard: Exact ATA specification draft version not indicated" und das finde ich Kacke von Western Digital.

Wenn mit einer verrät, wie man mit hdparm an die HDDs kommt, setze ich hdparm -D auf eine Platte ab und vermelde dann den LED-Status.

Der engl. Thread bezieht sich auf externe HDDs. Es hört sich so an, als ob interne Platten deaktiviert werden sollen. Das Kommando "fisk" kennt zumindest "mein" NAS nicht.

Wieso glaubst Du, bei einem 3,5"-NAS wie dem TS-419 einen Einschubadapter für 3,5" Festplatten zu brauchen? Die Platten müssten, sofern sie nicht irgendwelche exotischen Spezialmaße haben, in die Laufwerkseinschübe passen.
Mit den HDDs habe ich auch mal geliebäugelt, weil Seagate auf die Enterprise-Linie fünf Jahre Garantie gibt. Letztlich hab' ich's gelassen, weil die mir zuviel Strom in Wärme umwandeln.

Es bestünde vielleicht die Möglichkeit es über ssh mit chgrp, chown oder chmod zu versuchen. Das sollte klappen, sofern Du Adminstrator-Rechte hast.

Du könntest irgend eine Art "Diffusorfolie" davorkleben, die das LCD abdunkelt und das Licht etwas streut. Z.B. selbst basteln mit Klarsichtfolie oder kaufen - z.B. für Digitalkameras kann man doch so Klebefolien auf das Display kleben.

Das AD repliziert sich doch von selbst dauernd. Mir fällt grad nur ein Tool ein, mit dem man das beobachten kann: replmon.

Ja und ja. Festplattenkonfiguration JBOD. Synchronisieren "im" Gerät: rsync, mit PC (Dose) z.B. robocopy oder xcopy.

Schwer zu sagen, weil die Fehlemeldung fehlt. Bist Du nach Handbuch vorgegangen und hast den Initiator auf dem Recher mit dem Zieldienst auf dem NAS verbunden?
Evtll hilft System Connection Logs, Options, iscsi anhaken und logs durchwühlen.

Ich glaub', Robocopy funktioniert nur mit FAT und NTFS gut, mit EXT kann es nicht soviel anfangen. Ich habe ohne Erfolg versucht, Verzeichnisse zwischen NTFS->EXT zu synchronisieren (mit dem Schalter /MIR für Mirror). Oberflächlich schien alles geklappt zu haben, aber Robocopy erkannte Quelldateien nicht als geändert, wenn man innherhalb des MP3 Tags was geändert hatte.

Ebenfalls keine Probleme mit dieser Konfiguration an SS-839 mit 3.3.2 Build 0819T.

Die "Übertragungsbandbreite" im Ressourcenmonitor lügt doch, oder?

Ich habe beide LAN-Schnittstellen des NAS in einen "Netzwerk Port-Trunk" mittels IEEE 802.3ad (LACP, Link Aggregation Control Protocol) zusammengefaßt und auch am Switch die Ports mit diesem Protokoll gebündelt. So bekommt man mit dem Windoof-Tool "Teracopy" beim Kopieren großer Dateien so zwischen 30~110 MB Übertragungsrate angezeigt. Die Übertragungsbandbreite im Ressourcenmonitor lag in der Spitze bei "304 MB". Oder zeigt der Mbit/sec an?

EDIT: Screenshot