-f und -nsv ist das Problem.
Er glaubt, dass -n einen non-destructive scan durchführt,
während es in der Realität einen non-destructive read-write durchführt.
Was nicht weiter schlimm wäre, aber er forciert (-f) das Ganze auf einem ›mounted‹ Filesystem.
Gratulation!
PS. Zumindest kann man dann mal wieder über dieses ›Linux‹ meckern. ;-)
Er glaubt, dass -n einen non-destructive scan durchführt,
während es in der Realität einen non-destructive read-write
durchführt.
Sinn der Übung scheint gewesen zu sein, jeden Block einmal zu lesen und zurückzuschreiben (geht ja um „data refresh“) – wird ihm also klar gewesen sein, dass es liest und schreibt, weil er’s genau deswegen gemacht hat.
Was der Unsinn soll, auf einem eingehängten Dateisystem zu arbeiten, erschließt sich mir hingegen auch nicht. Einen USB-Stick für grml oder irgendein anderes Livesystem wird wohl jeder noch irgendwo auftreiben können.
Was der Unsinn soll, auf einem eingehängten Dateisystem zu arbeiten,
erschließt sich mir hingegen auch nicht. Einen USB-Stick für grml oder
irgendein anderes Livesystem wird wohl jeder noch irgendwo auftreiben
können.
Muss man doch noch nicht einmal.
›systemctl rescue‹,
dann ›mount -oremount,ro‹ und ab geht die wilde Fahrt.
Wenn fertig, Ctrl-D…
Jetzt musste ich doch gleich noch einmal nachsehen.
Ja, hast recht. Ich hatte mich von:
…to refresh a harddrive or flash media…
einlullen lassen.
Anyway, so etwas sollte man doch zehn mal nachprüfen und vor der Veröffentlichung dann noch einmal.
Anyway, so etwas sollte man doch zehn mal nachprüfen und vor der
Veröffentlichung dann noch einmal.
Hm. Er sagt, dass es um HDD und Flash gehen soll, und dass er mit HDDs anfängt „Let’s see how to refresh a harddrive or flash media in the Linux terminal. Starting with harddrives, we can read and rewrite all data using badblocks […]“.
Sorry, hier kann ich deinen Kritikpunkt nicht nachvollziehen.
Hm. Er sagt, dass es um HDD und Flash gehen soll, und dass er mit HDDs
anfängt „Let’s see how to refresh a harddrive or flash media in the
Linux terminal.
Starting with harddrives, we can read and rewrite all
data using badblocks […]“.
Sorry, hier kann ich deinen Kritikpunkt nicht nachvollziehen.
Der Punkt ist folgender:
Das Dateisystem ist /mounted/ es kann und wird also jederzeit und völlig unvorhersehbar vom laufenden System gelesen und beschrieben.
›badblocks‹ liest und schreibt während dessen ebenfalls auf dem physikalischen Datenträger herum, eine logische Etage darüber.
Das ist ein Rezept für ein Desaster, wenn nämlich zwei unterschiedliche Prozesse unterschiedliche Versionen von Daten an der gleichen Stelle auf die Platte schreiben.
Das kann beim Superblock passieren, das kann bei den alle 32MiB*¹ auftretenden inode-Strukturen des EXT2/3/4 auftreten, das kann bei regulären Daten auftreten.
Der Punkt ist folgender:
Das Dateisystem ist mounted es kann und wird also jederzeit und völlig
unvorhersehbar vom laufenden System gelesen und beschrieben.
Ja, schrieb ich ja selbst. Ich sah den Punkt im gequoteten Beitrag nicht, weil dort kein Bezug zu diesem Punkt vorhanden ist.
ZFS kann scrub natürlich auch wenn das Laufwerk gemounted ist.
Natürlich, denn es ist die einzige Instanz welche auf dem Plattenbereich herum wuselt. Lass die oben angeführte ›badblocks -nsvf‹ parallel darauf los und sei bereit zu staunen.
Die Kommentare unterm Vid muss man sich mal durchlesen, dort findet man
noch beklopptere Tipps.
Absolut. Die Menge von Jubelkaspern ist atemberaubend. Ich habe einen einzigen (Felix...) gefunden, der ähnliche Bedenken angemeldet hat. Unter Tausenden.
Aber es zeigt auch sehr schön, dass Menschen wirklich jeden Mist für glaubwürdig und richtig halten, wenn es nur mit genug Nachdruck vermittelt wird. Freue mich schon (nein, nicht wirklich) wenn AI von all denen ebenso unreflektiert eingesetzt wird. Und dann in Bereichen welche uns alle berühren.
›badblocks‹ liest und schreibt während dessen ebenfalls auf dem
physikalischen Datenträger herum, eine logische Etage darüber.
Ich wusste ueberhaupt nicht, dass dieses Kommando ueberhaupt noch "funktioniert", denn badblocks soll eigentlich direkt auf den physikalischen Platter via direkten head/block/sector-Zugriff zugreifen. Eine "Badblock-Liste" kenne ich nur noch bei ST506-Device oder alten SCSI-Platten (wo der Controller Kenntnis von der Geometrie des Devices hat, so dass der Zugriff auf die Platters optimiert wird).
Heutige Controller (seit ca. 1995) machen ja das badblocks-Management selbst (genauer gesagt auf dem Device) so dass die Ergebnisse bei Badblocks zweifelhaft sind (den Effekt des Caches auf dem Device darf man auch nicht vergessen).
Das ist ein Rezept für ein Desaster, wenn nämlich zwei unterschiedliche
Prozesse unterschiedliche Versionen von Daten an der gleichen Stelle auf
die Platte schreiben.
Das kann beim Superblock passieren, das kann bei den alle 32MiB*¹
auftretenden inode-Strukturen des EXT2/3/4 auftreten, das kann bei
regulären Daten auftreten.
so etwas wie dd if=/dev/random of=/dev/sda bs=1M count=1K wird Dein Filesystem bestimmt nicht ueberleben. Spannend ist aber, dass die Zuordnung logischer Sektor <-> physikalischer Sektor bei Flash-Devices vom Wear-Management kontrolliert wird. Zwei logisch zusammenliegende Sektor liegen nicht unbedingt physikalisch zusammen.
Ich wusste ueberhaupt nicht, dass dieses Kommando ueberhaupt noch
"funktioniert", denn badblocks soll eigentlich direkt auf den
physikalischen Platter via direkten head/block/sector-Zugriff zugreifen.
Eine "Badblock-Liste" kenne ich nur noch bei ST506-Device oder alten
SCSI-Platten (wo der Controller Kenntnis von der Geometrie des Devices
hat, so dass der Zugriff auf die Platters optimiert wird).
Ja, die greifen ›nur‹ noch über LBAs zu. Aber adressieren im Endeffekt natürlich ebenfalls Sektoren, in den meisten Fällen 2^9 Bytes oder 2^12 Bytes groß.
Aber diese Lese/Schreibzugriffe kneten die Magnetische Schicht ordentlich durch und geben dem von dir erwähnten Block-Mapping Mechanismus die Chance sich zu beweisen. Wenn dann immer noch badblocks heraus purzeln, dann wird's aber richtig Zeit… ;-)
so etwas wie dd if=/dev/random of=/dev/sda bs=1M count=1K wird Dein
Filesystem bestimmt nicht ueberleben.
Das ist die schnelle Methode, aber schreibt auch nur ein GiB am Anfang. Bei großen Platten bleiben da noch eine Menge (schwierig, aber nicht unmöglich) erreichbarer Daten übrig.
Aber es zeigt auch sehr schön, dass Menschen wirklich jeden Mist für
glaubwürdig und richtig halten, wenn es nur mit genug Nachdruck
vermittelt wird. Freue mich schon (nein, nicht wirklich) wenn AI von all
denen ebenso unreflektiert eingesetzt wird. Und dann in Bereichen welche
uns alle berühren.
Genau /das/ halte ich persönlich für die zweitgrößte existentielle Gefahr der kommenden Jahrzehnte.
Wenn man Werkzeuge nicht versteht…, dann liegt das daran das die Entwickler, bzw. Programmierer nicht fähig sind eine korrekte und verständliche Bedienungsanleitung zu schreiben.
Wenn man Werkzeuge nicht versteht…, dann liegt das daran das die
Entwickler, bzw. Programmierer nicht fähig sind eine korrekte und
verständliche Bedienungsanleitung zu schreiben.
Nee. Liegt (zumindest hier) eher daran, daß betreffende User unfähig oder nicht willens sind, die vorhandene Dokumentation zu finden, zu lesen und zu verstehen.
