Festplatten mit schwebenden Sektoren sind IT-Schrott.
Unsinn, schwebende Sektoren sind bei HDDs normal, sofern sie eben nicht in einem RAID laufen wo diese sofort wieder überschrieben werden.
Eine Reparatur ist faktisch nicht möglich, ein sprunghafter Anstieg ist jederzeit möglich.
Ein sprunghafter Anstieg ist ein Hinweis auf einen Defekt und ein Defekt ist jederzeit möglich. Aber Schwebende Sektoren sind erstmal nur Sektoren deren Daten nicht mehr zur ECC passen die hinter jedem Sektor steht und mit deren Hilfe auch nicht mehr korrigiert werden können. Da die korrekten Daten nicht mehr feststellbar sind, gibt die Platte statt falscher Daten einen Lesefehler als Antwort wenn man versucht diese zu lesen. Das kann auch anderen Gründe als defekte Oberflächen haben, z.B. einen Stromausfall während eines Schreibvorgang der dazu führt, dass eben nicht die ganze Daten plus der neuen ECC geschrieben wurden oder wegen eines Stoßes oder Vibrationen ist der Kopf beim Schreiben aus der Spur gekommen und hat Daten auf der Nachbarspur überschrieben. Auch arbeiten HDDs nicht 100%ig und die Hersteller geben die Fehlerhäufigkeit auch in Form der UBER an, wobei eine UBER von 1:10^14 bedeutet, dass je 10^14 gelesener Bits was etwa 12TB gelesener Daten entspricht, ein Lesefehler und damit schwebender Sektor im Rahmen der Erwartungen liegt.
Die Controller merken sich die schwebenden Sektoren und prüfen die Daten nach dem erneuten Schreiben auf diese Sektoren, dann verschwinden diese einfach oder werden eben durch Reservesektoren ersetzt, zuviel zu "eine Reparatur ist faktisch nicht möglich".
Festplatten mit schwebenden Sektoren werden immer aus einem Raid /0/1/5/6 geworfen.
So ein Unsinn, sorry aber du hast keine Ahnung und auch nichts verstanden! Denn mal vom RAID 0 abgesehen, welches mangels Redundanz kein echtes RAID ist, da das R in RAID ja für Redundant steht (es ist also eigentlich ein AID 0), zeigen HDDs in einem echten RAID normalerweise keine schwebenden Sektoren. Einfach weil die RAID Controller / SW bei Lesefehlern die Daten aus den Daten der anderen Platten (und damit auch der Parity) rekonstruiert und den fehlerhaft gelesenen Sektor überschreibt.
Rausfliegen tun nur HDDs die nicht innerhalb des Timeouts des RAID Controller antwortet, der gewöhnlich bei 8s liegt. Da geht es also um die TLER / ERC und damit nur indirekt um schwebende Sektoren. Das Problem passiert eben immer dann, wenn ein Sektor nicht mehr korrekt gelesen werden kann und dann probieren es alle HDDs durch wiederholtes Lesen diese doch noch korrekt zu Lesen (außer bei Nutzung von besonderen Befehlen oder Konfigurationen) und geben es irgendwann auf. TLER / ERC besagt nur, dass man einstellen kann wie lange die HDD es versucht und dass die Einstellung ab Wert kürzer ist, eben kürzer als die üblichen 8s die ein HW RAID Controller wartet und damit meldet die HDD dann eben einen Lesefehler und fliegt nicht aus dem RAID, stattdessen rekonstruiert das RAID die Daten und überschreibt den Sektor.
Platten die eben kein TLER / ERC haben (wie üblicherweise die Desktopplatten) und es daher üblicherweise länger als 8s probieren (bei WD ist oder waren es zumindest mal 14s), fliegen dann nach 8s aus dem RAID wenn sie es nicht geschafft haben. Sollten sie es dann aber doch noch schaffen den Sektor zu lesen, haben sie nicht einmal einen schwebenden Sektor, meistens werden sie es aber nicht schaffen und haben dann eben einen schwebenden Sektor und sind aus dem RAID geflogen. Mit der UBER hat das also nur in dem Sinne zu tun, dass eben eine HDD mit einer besseren UBER wahrscheinlich wenig früh so ein Problem haben wird.
In diesem Fall ist ein Rebuid erforderlich.
Ein Rebuild ist erforderlich, wenn der Zustand degradiert ist und nur beim Rebuild eines RAIDs wird die UBER von deren Platten relevant.
Wenn ich lese, welche Tipps gelegentlich hier im Forum zu diesem Thema gegeben werden, sträuben sich mir oft die Nackenhaare.
Meine Nackenhaare standen ab, also ich diesen Betrag gelesen habe, da er zeigt wie wenig du verstanden hast. Aber wenig Ahnung zu haben hindert ja heutzutage kaum nich jemanden daran vehement seine Meinung kund zu tun und diese Händen und Füßen zu verteidigen.
Ich habe hier zwei Raid5 mit je sechs ST3000DM001. Diese Platten sind für alles bekannt,
aber nicht für Zuverlässigkeit oder für Raid-Tauglichkeit. Damit laufen sie auf jeden Fall außerhalb jeder Bestimmung.
Desktopplatten im RAID 5 an einem HW-RAID Controller sind das perfekte Rezept dafür das sie früher oder später aus dem RAID fliegen, s.o.!
Meine Raid-Controller (LSI) bieten die Möglichkeit einen Konsistenz-Check durchzuführen.
Das nennt man Scrubbing, nur sollte man es nicht oft machen, denn gerade Desktopplatten haben kein sehr hohes Workload Rating. Mehr als einmal im Monate würde ich nicht empfehlen, aber ab und zu sollte es ein, einfach um zu erkennen, ob es schon Probleme mit einem Sektor gibt.
Das bedeutet, von allen 12 Platten werden allen Daten gelesen und die Checksummen verglichen.
Wenn man so will, ist das ein simulierter Rebuild.
Nicht wirklich, denn je nachdem was der Controller protokolliert, sieht man da gar nicht, ob es einen Lesefehler gab und der Controller überschreibt die betroffenen Sektoren dann einfach.
Dieser wird übrigens automatisch einmal die Woche gestartet und in der Management - Konsole protokolliert.
Bei 3TB sind 50 komplette Lesevorgänge im Jahr ein Workload von 150TB, ausgelegt ist sie aber nur für 55TB/Jahr. Nach etwas über 2 Jahren (mehr oder weniger) Dauerbetrieb und so ungefähr 20.000 Betriebsstunden kannst du mit Problemen bei den Platten rechnen, denn sie sind für diesen Einsatz mit den Belastungen nicht gemacht.
sollte ich jede Woche mindestens einen, wenn nicht sogar zwei Raidausfälle haben.
Wie kommst Du darauf? Du bist ein Troll, denn Du ignorierst die im Post #93 noch mal zitierten Aussagen das so ein Fehler eben nicht mit der Häufigkeit vorkommen muss, dann verwechselst du Scrubbing mit einem Rebuild und weist vermutlich nicht einmal wie oft dabei überhaupt Lesefehler ausgetreten sind, denn ein Srubbing bricht nicht ab oder gilt als gescheitert wenn es auf einen Lesefehler stößt, es ist ja vielmehr gerade dazu da diese Fehler (also schwebende Sektoren) zu finden und zu beheben. Es kann also durchaus sein, dass du bei 2 von 3 Scrubbings auf einer Platte einen Lesefehler hattest ohne es zu wissen.
Und deswegen bekommt dein Satz ein eigenes Kapitel im Buch „Moderne IT-Märchen“ 
Und du auf meine Ignoreliste, denn ich gebe es so jemandem noch etwas beibringen zu wollen.
- - - Updated - - -
3. Die UBER hat in etwa die Aussagekraft vom MHD (Mindesthaltbarkeitsdatum)
Das begreift er nicht oder will nur stänkern, dabei steht es oft genug im Thread.
Ein Raid gilt bei einer Belegung von 80% als Voll > beim Konsistenzcheck müssen also bei einem gut gefülltem Raid etwa 14,4 TB Daten gelesen werden
Vielleicht bei ZFS oder anderen Filesystemen mit integrierter RAID Funktion, aber er hat einen HW-RAID Controller und die wissen wie alle reinen RAID Lösungen (also auch md-RAIDs) eben nichts von der Belegung des RAID und müssen daher die RAIDs über die ganze Kapazität prüfen.
Daraus folgt daß du etwa alle 5-6 Konsitenzprüfungen irgendwo einen URE auf einer der beteilgten HDDs haben könntest.
Davon weiß er aber nichts, denn darüber berichten die meisten RAIDs nichts, weil die Prüfung eben genau dazu dient schwebende Sektoren zu erkennen und zu beseitigen, eben damit diese möglichst beseitigt sind bevor ein Rebuild ansteht oder bevor es am Ende zwei an der gleichen Stelle auftreten und damit eine Rekonstruktion der Daten an der Stelle nicht mehr möglich sein wird.
Apropos, welche Checksummen werden bei deinem Raid verglichen? Das muß ja ein Prototyp sein, da käuflich zu erwerbende Raidcontroller nur mit Paritätsdaten arbeiten.
Wie wenig Ahnung, Verständnis und Lernbereitschaft vorhanden ist, sieht man doch an den Beiträgen.
