Neuer potenter, aber effizienter Heimserver

Current Pending Sectors sind nicht defekte Sektoren die getauscht wurden sondern Sektoren die nicht gelesen werden konnten aber noch nicht getauscht wurden. Die tatsächliche Anzahl der Sektoren sollte sinken wenn diese Sektoren entweder neu geschrieben und gelesen wurden (also wieder ok sind) oder als uncorrectable ausgetauscht wurden.

Die Festplatte kann sich noch nicht entscheiden ob der Sektor kaputt ist. Egal, sobald sowas auftritt weg mit dem Shit.
Pack die in ne Externes gehäuse wos nicht so wichtig ist.

Das ist interessant: Eignetlich sollte die Datei doch dank Parity auch jetzt lesbar sein oder?
Und wenn DeBaschdi jetzt einen Paritycheck gemacht hätte, was passiert dann mit der Parity wird die angefasst und geändert?

Nicht unbedingt, da sie ja vorher evtl. schon auf dem defekten Sektor war, bevor die Parity geschrieben wurde.

Bei BTRFS oder ZFS wäre das aber direkt aufgefallen, weil ja die Checksummew nicht mit der geschriebenen Datei übereinstimmt oder?

Zitat von Simaryp

Bei BTRFS oder ZFS

Unraid nutzt ja beide Systeme. Und ohne Parity kein Error.

mea culpa xfs,zfs,btrfs,reiserfs ... zuviel fs für mein hirn ;P

Zitat von DeBaschdi

Kapier ich nicht...
Auch nicht nach dem 5x Lesen

Platte hat 0x00 "pending sectors".
Platte muss sektoren lesen weil user film schauen will. Einer der Sektoren (sagen wir 42) ist unlesbar.
Platte liefert passenden Fehler, z.b. "I/O error". Sieht man in linux mit 'dmesg' vom kernel [definition='1','0']log[/definition], da sollte auch die sektornummer drin stehen.
Weil lesen schief ging legt platte intern ein remapping an. Dazu hat sie intern mehr sektoren als sie dem Benutzer als les/schreibbar verkauft. 42 -> 184369274 (pending). Pending ist ein bit, so das die Platte weiss, das beim Lesen von 42 immer noch probiert werden soll, den originalen Sektor 42 zu lesen. Der PC hat ja noch nicht probiert, 42 zu ueberschreiben, sondern versucht immer noch 42 wieder und wieder zu lesen, wahrscheinlich weil die datei die Lottozahlen von 2020 enthalten.
Im SMART output meldet die Platte die Anzahl solcher pending remapped Sektoren.
Wenn der PC endlich mal Sektor 42 schreibt, merkt sich die platte das:42 -> 184369274 (). Der im SMART gemeldete pending count geht einen nach unten. Dafuer wird die anzahl der Remapped Sektoren um eins erhoeht.

Wenn man da jetzt kein backup oder andere redundanz (RAID, unRAID, snapRAID) hat, und die Lottozahlen retten will:

Unter linux gibt es "ddrescue" (nicht dd_rescue, das gabs auch mal ist aber nicht so gut).

Damit kann man eine Datei kopieren, aber das bricht bei Lesefehler nicht ab, sondern kopiert erst mal alles was es lesen kann aber merkt sich welche sektoren in der datei nicht lesbar waren. Und probiert es dann wieder. Vor allem liest/schreibt es erst grosse bloecke, z.b. 64k, und wenn die 64k nicht lesbar sind, probiert es im zweiten durchlauf z.. je 32kb. Aka: es ist effektiv, aber am ende fehlt nur wirklich der kleine physikaliscche sektor von der platte der kaputt ist. Und wenn der gluecklicherweise in einer mediendatei liegt (und nicht etwa zu keiner datei, sondern zu file-system metadaten gehoert), dann faellts vielleicht gar nicht auf. Kurzer kleiner blib im film, so wie auch bei digitalem Fernsehen, wenn da mal nicht alles perfekt ist.

Statt das mit einer datei zu machen, geht das halt auch mit der ganzen platte:

ddrescue /dev/sdc /disk/groessere-platte/sdc-sicherung [mapfile]

Wo /dev/sdc die kaputte platte ist, und das ziel halt entweder eine datei auf einer groesseren platte mit genug platz ist oder man kopiert auf eine ebenso grosse platte direkt (/dev/sdd als beispiel).

Level 2 von Datenrettung ist dann das ddrescue mit dem mapfile parameter laufen zu lassen, dann bleiben am ende die nicht lesbaren sektoren uebrig. Dann legt man die platte ins gefrierfach fuer eine stunde, und dann schnell nochmal ddrescue anschmeissen. Vielfach werden platten wirklich nur "weich" durch zuviel und zulange hitze, und wenn man die dann liest wenn sie kalt ist kriegt man noch mal viel mehr sektoren gelesen.

Mir ist mal eine 2TB Platte meiner set-top-box kaputt gegangen, da habe ich durch 4 gefrierfach-zyklen fast alles mit ddrescue gerettet bekommen. Allerdings ging das auch deswegen so gut, weil die set-top-box halt die dateien komplett separat von den metadaten haelt (eigenes file-system), und die metadatan waren halt nicht kaputt. Sobald man halt mal kaputte sektoren in den Metadata hat verliert man halt viele unschuldige/nicht-kaputte sektoren, weil man halt nicht mehr weiss welche sektoren zu lwelcher datei gehoeren. Hab bisher noch nicht versucht eine Meinung zu haben, welches File-system was man unter linux hat fuer Gefrierfachrecovery am besten waere

Zitat von DeBaschdi

Ich hab noch keine Parity, ich kopiere erstmal alles von alt auf neu

Ich dachte unraid sei auch standardmäßig copy on write?

Vielen Dank für die Erklärung der Festplatte te36.

@Simaryp

Erstbefüllung geht halt wesentlich schneller ohne gleich die Parity mit zu schreiben.

Würde die HDD Mal schon formatieren ,(Minitools Partitionsmanager empfehlen kann ich)

Dort die HDD Mal wipen mit lauter Nullen. Dann Kommandozeile: chkdsk [Laufwerk] -f

Dann neues Laufwerk erstellen und dann müsste diese schwebenden Sektoren erledigt sein.... Meldung" C5"

agarnele hat recht. Schwebende Sektoren sind nichts wildes und kommen immer wieder mal vor. Auch defekte Sektoren sind nichts wildes, eine Festplatte hat Sektoren um diese defekte zu ersetzen.

Schwebende Sektoren werden durch richtiges formatieren, also Nullen, bereinigt oder als wirklich defekt erkannt und aussortiert