Hier ist eine schöne Anleitung wie man sich seine Daten zerstören kann ohne sich darüber im Klaren zu sein. Besonders gut geeignet für Anfänger (oder die 1,2 Millionen Abonnenten) https://youtu.be/1B7yg7LWiik?si=tyV0c6Kvc8xVYcU_&t=911 -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. ;-)
Norbert schrieb: > https://youtu.be/1B7yg7LWiik?si=tyV0c6Kvc8xVYcU_&t=911 Über zwei Minuten Gehirnwäsche-Spot 1 von 2, nicht überspringbar -- nein, danke ...
Norbert schrieb: > 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.
Johannes F. schrieb: > Über zwei Minuten Gehirnwäsche-Spot 1 von 2, nicht überspringbar -- > nein, danke ... Den Browser richtig einrichten ist die allererste Bürgerpflicht zum Selbstschutz.
Jack V. schrieb: > Sinn der Übung scheint gewesen zu sein, jeden Block einmal zu lesen und > zurückzuschreiben Aber er macht's mit einer SSD (Partition), die soll laut seiner Aussage jedoch nur gelesen werden. Jack V. schrieb: > 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…
:
Bearbeitet durch User
Norbert schrieb: > Aber er macht's mit einer SSD (Partition), die soll laut seiner Aussage > jedoch nur gelesen werden. Nein, in dem Teil geht’s um HDD. Um SSD geht’s genau danach: Da lässt er ’n ›grep -r‹ auf das Dateisystem los.
Jack V. schrieb: > Nein, in dem Teil geht’s um HDD. 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.
Norbert schrieb: > 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.
Jack V. schrieb: > 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. ›badblocks‹ warnt sogar noch eindringlich. 1) Aus dem Gedächtnis.
Norbert schrieb: > 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. Schön mittels cronjob einmal im Monat.
Gustl B. schrieb: > 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.
Norbert schrieb: > -f und -nsv ist das Problem. Die Kommentare unterm Vid muss man sich mal durchlesen, dort findet man noch beklopptere Tipps.
Frank D. schrieb: > Norbert schrieb: >> -f und -nsv ist das Problem. > > 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.
Norbert schrieb: > ›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.
:
Bearbeitet durch User
Thomas W. schrieb: > 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… ;-) Thomas W. schrieb: > 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.
:
Bearbeitet durch User
Norbert schrieb: > 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.
BirnKichler S. schrieb: > 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.
BirnKichler S. schrieb: > dann liegt das daran das die So denkt man wohl wenn man in einer Knalltüten Manufaktur lebt.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.