Beiträge von anybody

    Bei meiner Konfiguration 8x8TB (TS853A) dauert das Tage!


    Wie kann ich die aktuell laufende synchronisation gefahrlos abbrechen?
    Ein NAS Neustart hat zur Folge gehabt, dass die synchronisation jetzt wieder bei 0% gestartet ist. :cursing:

    cat /proc/mdstat
    (um herauszufinden wie die device names heissen bei denen der rebuild läuft und was der status ist)


    echo idle > /sys/block/md0/md/sync_action
    (resync bei device md0 stoppen)


    Zur Performance:
    https://www.cyberciti.biz/tips…resync-rebuild-speed.html
    #4 und #5 würde ich ignorieren am QNAP, aber #1-#3 macht sinn.
    Falls es was bringt: Wie man die Optionen am QNAP so einstellt so dass sie dauerhaft auch nach Reboot aktiv sind ist ein anderes Thema - k.A.

    Seltsam. Stell das Buffering am MP3 Player höher ein :)


    Resync geschwindigkeit ist per Kommandozeile (ssh) zu bekommen:


    Code
    cat /proc/mdstat

    Zur Geschwindigkeit: Solange Clients darauf zugreifen, sei es auch nur für das Abspielen einer MP3 Datei wird die Resync Geschwindigkeit vermutlich nie überragend sein.
    Wirklich vollgas gibt er nur wenn er nix anderes zu tun hat.


    Die minimalgeschwindigkeit des Resync lässt sich per Kommandozeile natürlich auch hochsetzen - das würde dein "MP3-Problem" dann eher aber noch verschlimmern.

    Ich habe die Gelegenheit mal zum Anlass genommen das Scrubbing auf dem TS-659 Pro (Baujahr 2010, 6x 2TB im RAID6) zu starten. Geht dort nur per Kommandozeile da QNAP die neueste OS Version nicht mehr für das Modell rausgebracht hat.
    Synchronisation läuft hier mit 77MB/s (ich glaube dieser Wer bezieht sich pro Disk - also eigentlich 6x 77MB/s!) und hat eine geschätzte Restzeit von 7 Stunden.
    Während dies lief habe ich mal testweise ein 3GB ISO File vom QNAP auf einen PC kopiert. Ergebnis: LAN Transferrate im Bereich von circa 90MB/s und währenddessen Einbruch der Resync Geschwindigkeit auf circa 1MB/s. Danach wieder 77MB/s.
    Sowohl Geschwindigkeit als auch Priorität scheint beim TS-659 Pro wunderbar zu gehen. Es fehlt leider nur der GUI Menüpunkt :)


    Dass es bei Dir so langsam ist ist sehr sehr seltsam. Ich habe drei Vermutungen was es eventuell sein könnte:
    a) benutzt du vielleicht explizit nicht für RAID freigegebene SMR (Shingled Magnetic Recording) Festplatten, konkret die Seagate Archive HDD 8TB?
    b) hast du im QNAP vielleicht eine extra Verschlüsselung oder ähnliches eingeschaltet?
    c) vielleicht hängen irgendwelche installierten "Apps" mit dauernder 100% CPU Last im Hintergrund?

    Dir ist schon klar dass,wenn du deine Bremsen nur 1x im Halbjahr nutzt, diese komplett verrosten und du sie dann wegen Rost austauschen musst obwohl sie nicht abgefahren sind?
    Vernünftige Platten (und dazu muss es nicht die überteuerte Enterprise Serie sein) laufen auch in Servern wo sie 24/7 immer was zu tun haben (natürlich auch dort nicht immer Vollast) viele Jahre bevor sie irgendwann mal vielleicht kaputt gehen.

    Alles klaro, ist für größere RAIDs also nicht geeignet.

    Der Resync - auch Scrubbing genannt - prüft ob auf allen Festplatten alle Sektoren noch lesbar sind. Ist ein Sektor einer Platte nicht lesbar wird dieser Sektor aus den (Parity) Informationen der anderen 3 Disks neu berechnet und neu geschrieben. Dies führt bei Festplatten entweder dazu dass der Sektor neu geschrieben wird und nun wieder ok ist, oder dass beim Neuschreiben er als defekt markiert wird uns ein Reservesektor benutzt wird als Ersatz für den defekten. Ergebnis ist in jedem Fall wieder eine Festplatte auf der alle Sektoren lesbar sind.


    Beispiel Ausgangslage mit 4-Disk RAID5 :
    HDD 1 - Sektor 3771112 und Sektor 8799912 nicht lesbar
    HDD 2 - Sektor 9993321 nicht lesbar
    HDD 3 - ok
    HDD 4 - ok


    Mit Scrubbing:
    - Die 3 defekten Sektoren werden erkannt, neu geschrieben und HDD 1-4 sind nun wieder ok. Es gehen keine Daten verloren da auf HDD1 und HDD2 jeweils unterschiedliche Sektoren betroffen sind.


    Ohne Scrubbing:
    - Die 3 defekten Sektoren bleiben nicht lesbar es sei denn du greifst zufällig auf eine Datei zu die in diesen Sektoren liegt (eher unwahrscheinlich bei den heutigen Speichermengen)


    Nun geht Dir 2 Monate später plötzlich eine HDD kaputt. Nun hast du - wenn du kein Scrubbing gemacht hast - ein Problem! Und zwar egal WELCHE deiner vier Platten kaputt geht:
    Wenn Dir HDD1 kaputt geht kannst du 1 Sektor nicht mehr wiederherstellen (9993321)
    Wenn Dir HDD2 kaputt geht kannst du 2 Sektoren nicht mehr wiederherstellen (3771112 und 8799912)
    Wenn Dir HDD3 oder HDD4 kaputt geht, kannst du 3 Sektoren nicht mehr wiederherstellen (3771112 , 8799912 , 9993321)


    Wie sich der QNAP (bzw. der mdraid auf dem das basiert) verhält wenn nach dem Ersatz der defekten Festplatte auf den existierenden 3 Platten die Daten nicht überall lesbar sind weiß ich leider nicht.
    Aber selbst im BESTEN Fall hast du danach 3 korrupte Dateien ohne zu wissen welche es sind. Im schlechtesten Fall schlägt der Resync mit der neuen Festplatte fehl und du darfst dich von Hand darum kümmern die Daten zu retten und rauszufinden was eigentlich los ist.


    PS: Sonderfall beim Resync: Alle Daten lesbar aber bei einzelnen Sektoren passen die Daten und die Parity Information nicht zusammen - hier kann der Fehler nur protokolliert werden da RAID5 nur Fehlererkennung aber in diesem Fall keine Fehlerkorrektur erlaubt. Sollte aber eigentlich nie passieren, da die HDDs ihre Sektoren selber mit Prüfsummen absichern und zumindest theoretisch keine falschen Daten liefern SOLLTEN. Auch in der Praxis IMHO auch sehr selten.



    Zitat von TheRooster2000

    dann macht das bei meinen beiden QNAPs keinen Sinn

    Wenn Dir deine Daten nicht wichtig sind, ja, dann solltest du auf keinen Fall ein Scrubbing durchführen.


    Zur Geschwindigkeit: Im Optimalfall dauert ein Resync genau so lang wie es dauert eine Disk 1x komplett auszulesen - da alle Disks parallel arbeiten sollte es nicht von der Anzahl der Disks abhängen.
    In der Praxis kann es natürlich länger dauern, insbesondere manch älteres NAS hat nicht genug CPU Power um die Daten von allen Disks gleichzeitig zu verarbeiten ohne Performanceeinbruch.


    Bei einer 4TB Platte die mit durchschnittlich 100MB/s liest wären circa 12 Stunden für einen Resync realistisch - nur mal als Beispiel.
    Wenn es deutlich länger dauert als 24 Stunden kommt mir das - auf guter Hardware - etwas seltsam vor. Vielleicht bremsen gleichzeitige I/O Zugriffe der Clients den Resync vorgang? Standardmässig läuft der mit relativ niedriger Priorität und normale Zugriffe haben Vorrang. Lässt sich aber auf der Kommandozeile ändern.


    Beim Resync spielt sicher auch ne Rolle wie schnell sich die FP drehen, wieviel Cache die Platten haben und wie schnell der ist.

    Selbstverständlich ist bei einem Raid Resync die Größe und die Geschwindigkeit des Caches völlig irrelevant, da hier Daten sequentiell gelesen werden.
    Die Geschwindigkeit des Caches ist sowieso IMMER irrelevant da jeglicher Ram Cache IMMER schneller sein wird als ein SATA oder SAS Interface.


    Die Drehzahl der Festplatte ist auch nicht sonderlich relevant, denn es zählt ausschließlich der Datendurchsatz = Drehzahl * Datendichte.
    Der Durchsatz KANN bei einer höheren Drehzahl auch höher sein, muss aber nicht (es könnte z.B. nötig sein die Datendichte zu reduzieren damit der Kopf auch bei erhöhter Drehzahl es noch schafft die Daten zu lesen).

    Auf "normalen" Festplatten werden dann sinnvollerweise Dinge wie CheckDisk, o.ä. genutzt um nach Möglichkeit Daten die durch die Beschädigung korrupt geworden sind, wiederherzustellen oder zumindest einen Teil davon zu retten und dann diese Sektoren/Bereiche als defekt zu markieren und auf ReserveSektoren zuzugreifen.

    chkdsk macht dies im Normalfall nie. chkdsk repariert Inkonsistenzen im Dateisystem (üblicherweise entstanden durch Abstürze oder Stromausfall), und kümmert sich nicht um Hardware Probleme der Festplatte.


    Beim Scrubbing wird nur geschaut, welche Datenblöcke als event. defekt markiert wurden, nicht mehr benötigte Daten gelöscht und dann die Infos in die Paritätbytes geschrieben.
    Das Resync hat nichts mehr mit einem Test zu tun.

    Unter Scubbing versteht man normalerweise einen Resync. Wieso im QNAP log hier zwei verschiedene Begriffe auftreten ist seltsam.

    Eine "Dateibereinigung" kann ja wohl kein Scrubbing sein. Denn die hat absolut gar nichts mit Dateien zu tun sondern arbeitet auf dem mdraid Volume Sektorbasiert.
    In einer Diskussion zu QTS 4.3 Beta habe ich gefunden dass es evtl. ein "Speichermanager - Volume - Verwalten - Datenbereinigung Starten" geben soll. Vielleicht meinst du ja eine Datenbereinigung und keine Dateibereinigung?


    Davon ist aber nichts zu sehen am QNAP TS-659 Pro+ mit QTS 4.2.2 build 20160901 - siehe zwei angehängte Screenshots.

    Hier mal ein Bild wie ich eine Notebookplatte im TS-112 eingebaut habe.


    Letztendlich muss man nur auf dem Halterwinkel auf der einen Seite ein zusätzliches Loch bohren an der richtigen Stelle und dort eine Schraube durchstecken.
    Da es leider wegen dem Schraubenkopf nicht ganz 100% plan auflag auf der Unterlage habe ich dann noch ein paar Schichten Tesa verklebt damit die Platte eine perfekte Auflagefläche hat und nicht in der Luft schwebt (hat nur 1mm oder so gefehlt, nicht viel).


    Wenn QNAP ab Werk für zusätzliche 0,2cent das zusätzliche Loch bohren und ein Schraube mit kleinem Kopf beilegen würde wäre das Gerät auch ab Werk 2,5" tauglich. Wollen aber vermutlich den Absatz des Synology Type A und Type C Adapters ankurbeln (sind fast identisch, weiss nicht welcher der beiden besser passt), ist ja schliesslich deren Hauptkonkurrent :D