Aussehen
Suche Einloggen
[c] [meta] [fefe] [erp]

/c/ – Eine der letzten echten Webseiten


Antwort erstellen

(≤ 4)



[Zurück]

  • [l] Backup gemacht? Nein! Felix Sun, 20 Sep 2026 13:48:38 GMT Nr. 165201
    PNG 1002×1052 804.6k
    JPG 1536×1152 458.8k
    >05 Reallocated Sectors Count 200 200 140 0
    >C5 Current Pending Sector Count 200 200 0 2
    Absolute Anfängerzahlen

    >SMART values? More like snuff values.
    In der Tat, Felix hat ein anschauliches Beispiel mitgebracht, ratet mal welche SMART-Werte zu welchem Szenario gehören:

    *) Das Dateisystem einer der Platten ließ sich plötzlich nicht mehr besteigen. Mit ddrescue konnten noch 80% der Datenblöcke gelesen werden.

    *) Von der anderen Platte konnten noch ca. 1,5 Jahre nach SMART-Messung ohne Probleme Daten gelesen und geschrieben werden. Beim Schrubben vom ButterFS im Nachhinein traten 4 Fehler auf.

    [ 6452.637432] BTRFS info (device sdi): scrub: started on devid 1
    [10289.369651] BTRFS warning (device sdi): checksum error at logical 654567825408 on dev /dev/sdi, physical 656723697664, root 5, inode 1136, offset 496918528, length 4096, links 1 (path: █████/██████████/███/██████████████/█████████████████████████████████████████████████.███)
    [10289.369657] BTRFS error (device sdi): bdev /dev/sdi errs: wr 0, rd 0, flush 0, corrupt 3, gen 0
    [10289.369659] BTRFS error (device sdi): unable to fixup (regular) error at logical 654567825408 on dev /dev/sdi
    [19264.703969] BTRFS warning (device sdi): checksum error at logical 1895520681984 on dev /dev/sdi, physical 1872946937856, root 5, inode 2969, offset 844201984, length 4096, links 1 (path: █████/█████████/████████████/██████████████/█████████████/████████████████████████.███)
    [19264.703976] BTRFS error (device sdi): bdev /dev/sdi errs: wr 0, rd 0, flush 0, corrupt 4, gen 0
    [19264.703978] BTRFS error (device sdi): unable to fixup (regular) error at logical 1895520681984 on dev /dev/sdi
    [20456.231451] BTRFS info (device sdi): scrub: finished on devid 1 with status: 0
    


    ---

    === START OF READ SMART DATA SECTION ===
    SMART Status not supported: Incomplete response, ATA output registers missing
    SMART overall-health self-assessment test result: PASSED
    Warning: This result is based on an Attribute check.
    
    SMART Attributes Data Structure revision number: 16
    Vendor Specific SMART Attributes with Thresholds:
    ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
      1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       6
      3 Spin_Up_Time            0x0027   207   201   021    Pre-fail  Always       -       4625
      4 Start_Stop_Count        0x0032   099   099   000    Old_age   Always       -       1411
      5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
      7 Seek_Error_Rate         0x002e   168   168   000    Old_age   Always       -       781
      9 Power_On_Hours          0x0032   095   095   000    Old_age   Always       -       3749
     10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
     11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
     12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       639
    192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       494
    193 Load_Cycle_Count        0x0032   193   193   000    Old_age   Always       -       21078
    194 Temperature_Celsius     0x0022   131   104   000    Old_age   Always       -       21
    196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
    197 Current_Pending_Sector  0x0032   198   198   000    Old_age   Always       -       701
    198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
    199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
    200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0
    


    ---

    === START OF READ SMART DATA SECTION ===
    SMART overall-health self-assessment test result: FAILED!
    Drive failure expected in less than 24 hours. SAVE ALL DATA.
    See vendor-specific Attribute list for failed Attributes.
    
    SMART Attributes Data Structure revision number: 16
    Vendor Specific SMART Attributes with Thresholds:
    ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
      1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
      2 Throughput_Performance  0x0005   131   131   054    Pre-fail  Offline      -       116
      3 Spin_Up_Time            0x0007   135   135   024    Pre-fail  Always       -       436 (Average 410)
      4 Start_Stop_Count        0x0012   097   097   000    Old_age   Always       -       12823
      5 Reallocated_Sector_Ct   0x0033   001   001   005    Pre-fail  Always   FAILING_NOW 1577
      7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
      8 Seek_Time_Performance   0x0005   123   123   020    Pre-fail  Offline      -       34
      9 Power_On_Hours          0x0012   099   099   000    Old_age   Always       -       7966
     10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
     12 Power_Cycle_Count       0x0032   098   098   000    Old_age   Always       -       11754
    192 Power-Off_Retract_Count 0x0032   090   090   000    Old_age   Always       -       12825
    193 Load_Cycle_Count        0x0012   090   090   000    Old_age   Always       -       12825
    194 Temperature_Celsius     0x0002   253   253   000    Old_age   Always       -       18 (Min/Max 18/61)
    196 Reallocated_Event_Count 0x0032   012   012   000    Old_age   Always       -       1659
    197 Current_Pending_Sector  0x0022   092   092   000    Old_age   Always       -       322
    198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
    199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0
    

  • [l] Felix Sun, 20 Sep 2026 14:28:58 GMT Nr. 165202
    PNG 1002×1052 794.2k
    PNG 774×298 123.3k
    PNG 602×438 11.3k
    PNG 1500×880 119.3k
    >>165201
      9 Power_On_Hours          0x0032   095   095   000    Old_age   Always       -       3749
      9 Power_On_Hours          0x0012   099   099   000    Old_age   Always       -       7966
    


    Early death?

    192 Power-Off_Retract_Count 0x0032   090   090   000    Old_age   Always       -       12825
    193 Load_Cycle_Count        0x0012   090   090   000    Old_age   Always       -       12825
    


    Welches OS schafft das? Die Köpfe wurden ja anscheinend immer Notgeparkt und dann wieder heiß geladen. War das eine Maschine die du in der Industrie reparieren solltest?

    chkdsk hat hier jedenfalls nichts gebracht, aber nett, dass du das Bild gespeichert hast.
    Gefickt bin ich noch immer.

    Wollte ja das Energienetz als Sündenbock nehmen. Haben wir gestern ein 2200MW Kraftwerk verloren oder war das Markt-Preisgewichse?
  • [l] Felix Sun, 20 Sep 2026 14:34:46 GMT Nr. 165203
    JPG 1600×1067 504.7k
    Ja, der Faden war vor ein paar Stunden einfach von OP gelöscht, obwohl Felix seinen Pfosten fertig geschrieben hatte. Der lief dann in den 404. Aber Felix hatte seinen Pfosten gespeichert (Backup vom Pfosten gemacht? Ja!) und der folgt nun:

    Felix macht hier auf seine 2 Festplatten seit 5 Jahren seine Backups, und macht auch vor jedem Backup eine Hash-Prüfung. Bisher zum Glück noch nie einen Datenverlust/Bitrott.

    Felix hatte dafür ein skurriles Ergebnis auf einem Fenster-System vor ein paar Jahren: Felix saß vor Visual Studio und kompilierte was. Dann schwarzer Bildschirm und das System startete neu. "Nun gut, ist halt scheiße, aber weitermachen." Also wieder Visual Studio gestartet, kompiliert, und nun merkwürdige Kompilierfehler.

    Aber nicht in einer Datei in Felixens Quelltextbaum, sondern in einer Header-Datei der CRT in C:\Program Files (x86)\Windows Kits\10\Include\10.0.xxxxx.x\ucrt. Als Felix dann in die Datei reinschaute, sah zunächst alles normal aus, aber als er dann runterscrollte, sah er, dass irgendwann ein Block leerer Text mitten in der Datei drin war. In einem Hex-Editor sah man dann: Genau auf einer 4096-Byte-Grenze war ein 4096-Byte-Block nur mit 0en gefüllt.

    Felix hat durch Neuinstallation der CRT die Datei wiederherstellen können, aber die Erfahrung hat Felix immer mit einem mulmigen Gefühl zurückgelassen. War eine Samsung-SSD, das Hauptlaufwerk des Systems.
  • [l] Felix Sun, 20 Sep 2026 14:38:50 GMT Nr. 165204
    Das Problem ist doch ganz klar: Du hast auf Western Digital vertraut, und wunderst dich jetzt, dass die Pfutsch ist.
    Meine Seagates und Toshibas laufen jeweils Jahre ohne Probleme zu haben, z.B. mein altes Raid5 mit 3 Seagates ist 5 Jahre gelaufen, bevor eine der drei Platten ausgestiegen ist, aktuell laufen zwei Toshibas im Raid1 seit knapp zwei Jahren ohne irgendwelche Auffälligkeiten.
  • [l] Felix Sun, 20 Sep 2026 14:43:22 GMT Nr. 165205
    PNG 1175×1280 813.4k
    >>165203
    >Ja, der Faden war vor ein paar Stunden einfach von OP gelöscht, obwohl Felix seinen Pfosten fertig geschrieben hatte.
    Tschulligom, habe seit dem Erstellen und Löschen nur das gesamte System durchgetestet und alle Laufwerke, bis zum RAM und der CPU (prime) selbst.
    >Felix macht hier auf seine 2 Festplatten seit 5 Jahren seine Backups, und macht auch vor jedem Backup eine Hash-Prüfung. Bisher zum Glück noch nie einen Datenverlust/Bitrott.
    Ja ich hatte das Tool verlinkt mit dem Hinweis darauf, dass ein fulldisk.sha1 (oder jedes andere sha256, co) Dateisystem-agnostisch ist:
    https://github.com/idrassi/HashCheck
    >Felix hatte dafür ein skurriles Ergebnis auf einem Fenster-System vor ein paar Jahren: Felix saß vor Visual Studio und kompilierte was. Dann schwarzer Bildschirm und das System startete neu. "Nun gut, ist halt scheiße, aber weitermachen." Also wieder Visual Studio gestartet, kompiliert, und nun merkwürdige Kompilierfehler.
    *scheißt sich beim Lesen ein*
    >Aber nicht in einer Datei in Felixens Quelltextbaum, sondern in einer Header-Datei der CRT in C:\Program Files (x86)\Windows Kits\10\Include\10.0.xxxxx.x\ucrt. Als Felix dann in die Datei reinschaute, sah zunächst alles normal aus, aber als er dann runterscrollte, sah er, dass irgendwann ein Block leerer Text mitten in der Datei drin war. In einem Hex-Editor sah man dann: Genau auf einer 4096-Byte-Grenze war ein 4096-Byte-Block nur mit 0en gefüllt.
    Kennt das Fühl von Linux, als ich in meinen .confs mal nachgesehen habe, warum ein Dienst nicht ging und es war der Datenträger und die Konfiguration war solch ein Datenmüll.
    >Felix hat durch Neuinstallation der CRT die Datei wiederherstellen können, aber die Erfahrung hat Felix immer mit einem mulmigen Gefühl zurückgelassen. War eine Samsung-SSD, das Hauptlaufwerk des Systems.
    Mit denen hatte ich bisher Glück, Freunde eher weniger. Hatte die, die immer langsamer wurden und dann eine FW bekamen, die die schwachen triple level cells auffrischt. Damals war TLC noch so verhasst (weil neu) wie heute QLC NAND.
    Es ist vorbei. Jedenfalls mit der WD 2TB Red (Pro) mit PMR (kein SMR). Jetzt Neukauf bei bis zu 400% KI-Bubble zuschlag? Brauche ich! /s
  • [l] Felix Sun, 20 Sep 2026 16:15:06 GMT Nr. 165206
    WEBM 320×240 3:07 7.5M
    Felix ist froh, dass er Anfang des Jahres noch seine 12 Jahre alten 8TB-WD-Platten durch neue 22TB-WD-Platten ersetzt hat. Letztere kosten jetzt nämlich mehr als das Doppelte von dem, was Felix bezahlt hat :)

    Eigentlich wollte Felix das schon ein Jahr vorher machen, dann hätte er noch mehr für sein Geld bekommen, ging aber leider nicht aus $Gründen.

    Die alten Platten waren eigentlich noch in Ordnung, aber nach 12 Jahren Laufzeit wird man dann doch langsam etwas nervös. Beim Umkopieren der Daten auf die neuen Platten gab es ~3 Read Errors auf zwei der Platten, die dritte hatte 0 Errors. Die Fehler waren aber kein Problem, weil das natürlich ZFS war. Es ist gut möglich, dass sie sogar in einem unbenutzten Bereich lagen, weil bei vorherigen ZFS Scrubs nie irgendwelche Fehler aufgetreten waren.

    >>165204
    Meine WD-Platten haben bisher alle absolut solide gehalten, selbst über 10 Jahre im Dauerbetrieb und länger. Kollege musste damals in der Schule bei seinem neuen Gayming-Rechner seine Seagate fünf mal umtauschen, bis er eine hatte, die nicht nach zwei Wochen den Geist aufgab. Die Erfahrung hat sich Felix so sehr eingeprägt, dass er niemals Seagate kaufen wird. Die Statistiken (z.B. von Backblaze /erp) geben Felix recht. Seagate hat durchweg deutlich schlechtere Fehlerstatistiken als die anderen Hersteller, also ich meine so, nicht nur ein bisschen schlechter, sondern eine Größenordnung schlechter.

    Toshiba baut auch ganz ordentliche Platten. Hatte Felix auch mal in einem seiner früheren Rechner von der Stange, die liefen auch jahrelang problemlos. Wer vorne liegt, das hängt immer vom jeweiligen Modell ab. Aber WD und Toshiba sind beide gute Hersteller. Allerdings liest man in Rezensionen häufiger, dass die Toshiba-Modelle mit sehr hohen Kapazitäten recht laut sind. Das wäre für Felix störend. Allerdings muss man leider erwähnen, dass die Hochkapazitätsmodelle von WD im Betrieb auch alle fünf Sekunden oder so ein "Klick" von sich geben, was auch ziemlich nervig sein kann (gibt Videos davon auf Youtube. Und Fäden auf Habsgelesen, aber die lassen sich ja leider nich mehr abrufen). Allerdings ist das nach Felix Recherchen wohl heute bei allen Herstellern so ab einer gewissen Kapazität. Kann man nix machen. Wenigstens hört es nach einigen Minuten Idle auf. In Kombination mit einer ausrangierten SATA-SSD als Cache (L2ARC) lässt sich damit leben, weil die häufig benutzten Daten eh im Cache liegen und auf die Platten nicht so oft zugegriffen werden muss.

    Spaßfakt: Felix
    - hatte noch nie einen Festplattencrash
    - hat sich noch nie etwas gebrochen
    - hatte noch nie ein Loch im Zahn
    Wer kann mithalten?
  • [l] Felix Sun, 20 Sep 2026 16:45:02 GMT Nr. 165209
    >>165206
    Festplatten stellt man ja auch nicht ins Schlafzimmer.
    Und wenn man sich hochkapazitive Festplatten anschaut, dann muss man auch auf die Organisation schauen, Stichwort CMR vs SMR. Bei SMR müssen immer ganze Bereiche neu geschrieben werden, bei CMR nicht, entsprechend andere Performance, aber auch anderer Preis.
  • [l] Felix Sun, 20 Sep 2026 16:50:34 GMT Nr. 165210
    >>165209
    SMR würde ich höchstens für Backups in Betracht ziehen, aber nicht für die reguläre Benutzung. Und niemals nie nicht in einem RAID/ZFS/Btrfs!
  • [l] Felix Sun, 20 Sep 2026 17:08:25 GMT Nr. 165212
    /hannoveranerforummode==on
    Es ist PMR, weiß nicht woher "CMR" kam.
    https://www.youtube.com/watch?v=xb_PyKuI7II

    CMR wäre (wenn korrekt des conventional nach) prä-historisch longitudinal, was tatsächlich vor PMR kam.
    SMR ist einfach nur Krebs Stufe 4.
    Konventionell ist unpräzise, es ist Senkrechtaufzeichnung, was damals ein echter Fortschritt war.
    /KLUGSCHEIẞE==off
  • [l] Felix Fri, 25 Sep 2026 17:35:14 GMT Nr. 165271
    >>165261
    Was genau ist Knisterfolie für dich? ESE-Schutz? Ahoi-Brause-Folie? Und was genau soll neben "Knisterfolie" im Paket gewesen sein? Der Riesendildo für deine Mutter?
    Bitte sei doch in Zukunft präziser, so macht das echt keinen Spass mit dir!
  • [l] Felix Fri, 25 Sep 2026 17:38:42 GMT Nr. 165272 SÄGE
    ?
  • [l] Felix Fri, 25 Sep 2026 17:42:58 GMT Nr. 165274
  • [l] Felix Mon, 28 Sep 2026 18:19:28 GMT Nr. 165325
    Oh neim!


[Zurück]
[c] [meta] [fefe] [erp]