Mir sind 5 Festplatten zugelaufen. Jeweils 1TB gross,
alle noch mit akzeptablen Betriebsstunden (um 1,5k)
Die will ich löschen.
Ich bekomme hier an USB Löschraten um die 33MB/sek hin,
an SATA nicht wesentlich mehr.
Da mein Wissen noch auf gefährlichem Halbzustand ist,
muss ich dazu mal fragen, die "dd" genau vorgeht.
ich lösche grad eine Platte mit dem Befehl
1
dd if=/dev/zero of=xx.txt bs=1M
ist dabei eigentlich auch noch die Systemfestplatte beteiligt?
/dev/zero liegt ja dort.
wie fliessen die Daten da genau?
● J-A V. schrieb:> dd if=/dev/zero of=xx.txt bs=1M
also schreibt du in eine Datei? Festplatten löscht man in dem man auf
das Device schreibt
dd if=/dev/zero of=/dev/sda1 bs=1M
> /dev/zero liegt ja dort.
nein, dev liegt nirgends.
● J-A V. schrieb:> ist dabei eigentlich auch noch die Systemfestplatte beteiligt?>> /dev/zero liegt ja dort.>> wie fliessen die Daten da genau?
Nein. Es wird lediglich das Ziel geschrieben.
Plattenaktivität kannst du bspw. in 10s Intervallen mit "sar -d 10" oder
"iostat 10" monitoren.
ich lasse das in Dateien schreiben, die auf der Zielplatte landen.
Peter II schrieb:> nein, dev liegt nirgends.
und da fängt das gefährliche Halbwissen an... ;)
Siehe https://wiki.ubuntuusers.de/dd/
Wichtig bzgl. Geschwindigkeit: Ist der Cache wirklich nur 1MB groß?
Glaube ich nicht...
=> Im o. a. Link unter "Festplatten löschen" nachlesen.
● J-A V. schrieb:> ich lasse das in Dateien schreiben, die auf der Zielplatte landen.
Käse.
Kannst Du zwar machen, aber was Du wirklich willst, ist, das block
device so lange mit Nullen zu beschreiben, bis es "voll" ist.
Siehe meinen o. a. Link.
● J-A V. schrieb:> ich lasse das in Dateien schreiben, die auf der Zielplatte landen.
und warum? ein Dateisystem braucht man hier nicht und macht die ganze
Sache langsamer.
Peter II schrieb:> ● J-A V. schrieb:>> ich lasse das in Dateien schreiben, die auf der Zielplatte landen.>> und warum? ein Dateisystem braucht man hier nicht und macht die ganze> Sache langsamer.
und bei Unterbrechungen?
(Stromausfall etc)
-alles neu von vorne?
● J-A V. schrieb:> ich lasse das in Dateien schreiben, die auf der Zielplatte landen.
Warum das? Du weißt nicht, was das Dateisystem im Hintergrund macht
(deduplication, compression etc.). Außerdem wir das Dateisystem selbst
nicht überschrieben und es könnten in den dortigen Metainformationen
Daten erhalten bleiben.
Mach dein dd direkt auf /dev/sda, /dev/sdb oder wo auch immer deine
Platte hernach liegt. Wichtig: NICHT /dev/sda1 sondern wirklich
/dev/sda.
Danach musst du dann neu partitionieren.
● J-A V. schrieb:> und bei Unterbrechungen?> (Stromausfall etc)>> -alles neu von vorne?
ja, also ob man nach einen Stromaufall einen Dateisystem noch trauen
kann.
Wie oft ist bei dir der Strom weg, das dir wegen 5 Festplatten die man
gleichzeitig in 5-6 Stunden platte machen kann, sorgen machst?
> Mach dein dd direkt auf /dev/sda, /dev/sdb oder wo auch immer deine> Platte hernach liegt. Wichtig: NICHT /dev/sda1 sondern wirklich> /dev/sda.meckerziege schrieb:> Danach musst du dann neu partitionieren.
und windows behauptet die platte sei "farikneu". hihi.
Dann muss ich anders fragen:
Da ich einen Rechner z.B. nicht gerne unbeaufsichtigt
und auch nicht über Nacht laufen lasse,
suche ich eine Möglichkeit, eine Platte in mehreren "Sitzungen"
nach und nach zu überschreiben.
eine Fortschrittsanzeige für sowas wäre auch gut.
● J-A V. schrieb:> Da ich einen Rechner z.B. nicht gerne unbeaufsichtigt> und auch nicht über Nacht laufen lasse,> suche ich eine Möglichkeit, eine Platte in mehreren "Sitzungen"> nach und nach zu überschreiben.
Bei dd kannst du mit skip und Count angeben, ab welchem Block wieviele
Blöcke überschrieben werden sollen. Die grösse eines Blocks gibst du mit
bs an
http://askubuntu.com/questions/215505/how-do-you-monitor-the-progress-of-dd
Hier noch was zum lesen wie du eine fortschittanzeige +
schreibgeschwindigkeit erhältst. Wobei du beim pv die gesamtgrösse
zusätzlich angeben musst. Sonst stimmt die prozentzahl und der balken
nicht
nimm' einfach
https://sourceforge.net/projects/dban/
einstöpseln, anschalten, Kaffee trinken gehen... :-)
Zumindest wenn die Platte(n) wirklich komplett und
"restaurierungssicher" gelöscht werden sollen imo sehr brauchbar; nur
für's Löschen für den Eigenbedarf vielleicht etwas oversized...
● J-A V. schrieb:> Mir sind 5 Festplatten zugelaufen. Jeweils 1TB gross,> alle noch mit akzeptablen Betriebsstunden (um 1,5k)>> Die will ich löschen.> Ich bekomme hier an USB Löschraten um die 33MB/sek hin,> an SATA nicht wesentlich mehr.>> Da mein Wissen noch auf gefährlichem Halbzustand ist,> muss ich dazu mal fragen, die "dd" genau vorgeht.>> ich lösche grad eine Platte mit dem Befehl> dd if=/dev/zero of=xx.txt bs=1M
Du kopierst mit diesem Befehl den Inhalt des Zero-Device in die Datei
xx.txt.
Dafür werden Blöcke der Größe 1M verwendet.
Das Zero-Device ist kein physikalisches Gerät, sondern eine als Gerät
eingebundene Art Funktion, die nur Nullen liefert.
> ist dabei eigentlich auch noch die Systemfestplatte beteiligt?>> /dev/zero liegt ja dort.
Die Systemfestplatte ist bei /dev/zero als Datenquelle nicht beteiligt,
aber der Gerätetreiber, der die Nullen liefert, muss ja ausgeführt
werden.
Ich weiß nicht, wo der genau bei Linux liegt, ob im Kernel, oder einen
anderen Datei - auf dem Systemlaufwerk.
>> wie fliessen die Daten da genau?
Die Daten, also die Nullen, verlängern die Zieldatei solange, bis xx.txt
aus Platzmangel nicht mehr verlängert werden kann.
Diese Art der Löschung geht aber an Deinem Ziel vorbei.
c.m. schrieb:> aber eine 1TB Festplatte sollte bei durchschnittlich vielleicht 80MB/s> in 4 stunden durch sein.> haste kein USB3 oder eSATA gehäuse rumfliegen?
Wieso sollte USB3 oder eSata schneller sein, wenn er mit SATA-Anbindung
keinen signifikanten Geschwindigkeitszuwachs erzielt?
Benutze ddrescue anstelle von dd.
Die Fortschrittsanzeige gehört mit dazu, wie c.m. schon sagte.
Wenn Du beim Aufruf die Protkollfunktion in ein Logfile nutzt, kannst Du
zwischendurch die Löschaktion abbrechen und später wieder fortsetzen,
wenn Du ddrescue mit diesem Logfile aufrufst.
Einfacher geht es nicht.
Eine Festplatte löscht man allerdings nicht, indem man einfach eine neue
Datei auf eine formatierte Festplatte schreibt, wie schon Meckerziege
und PeterII erwähnten. Es bleibt ja alles Vorhandene unberührt!
Du solltest die Platte schon komplett löschen.
Das heißt, Du schreibst vom Nulldevice auf Device, das Deine Festplatte
darstellt. Dann sind auch Partitionen und MBR-Informationen oder
GPT-Informationen gelöscht.
Achtung, zwei Versionen von ddrescue sind verbreitet.
Die Version von Knut Garloff hat noch einen Unterstrich zwischen dd und
rescue. Nimm die GNU-Version.
Peter M. schrieb:> c.m. schrieb:>> aber eine 1TB Festplatte sollte bei durchschnittlich vielleicht 80MB/s>> in 4 stunden durch sein.>> haste kein USB3 oder eSATA gehäuse rumfliegen?>> Wieso sollte USB3 oder eSata schneller sein, wenn er mit SATA-Anbindung> keinen signifikanten Geschwindigkeitszuwachs erzielt?
das kommt wohl eher daher weil er in eine datei schreibt, anstatt auf
das block device.
Peter M. schrieb:> Eine Festplatte löscht man allerdings nicht, indem man einfach eine neue> Datei auf eine formatierte Festplatte schreibt, wie schon Meckerziege> und PeterII erwähnten. Es bleibt ja alles Vorhandene unberührt!
ich hatte von der Platte vorher alles gelöscht.
die ganze Platte war frei, bis aufs Dateisystem natürlich.
ist trotzdem besser die sektoren von 0-ende auszunullen anstatt in eine
datei zu schreiben.
ersteres löscht wirklich alles, letzteres macht nur doofen overhead.
Hast du mit df nachgeschaut, ob die Platte sich auch tatsächlich
auffüllt? Ich glaube zwar, dass Linux noch nicht prüft, ob ein ganzer
block ausgenullt ist, aber wer weiss, sparse files sind möglich. Ich
habe mal eben ein 15TB File auf meiner 195GB Partition erstellt, ist
schön "genullt", und ich habe immernoch 33GB frei:
Peter M. schrieb:> Die Systemfestplatte ist bei /dev/zero als Datenquelle nicht beteiligt,
In gewissem Sinne schon, denn dev ist ein mountpoint unterhalb von
und bei / ist nunmal die Systemplatte eingehängt.
Aber klar, beim Lesen von /dev/zero wird natürlich in keinster Weise auf
der Systemplatte rumgeschrammelt.
> Achtung, zwei Versionen von ddrescue sind verbreitet.> Die Version von Knut Garloff hat noch einen Unterstrich zwischen dd und> rescue. Nimm die GNU-Version.
Das trifft den Sachverhalt nicht ganz. dd_rescue ist eine leicht
gepatchte Variante von dd, bei der einfach nur Lesefehler ignoriert und
statt der wegen des Lesefehlers nicht gelesenen Daten Nullen in's Ziel
geschrieben werden.
ddrescue hingegen hat mit dd so gut wie nix gemein, sondern ist von
Grund auf speziell für die Datenrettung/Forensik designed worden. Die
einzige Verwandschaft zwischen dd_rescue und ddrescue besteht wirklich
nur in der Ähnlichkeit der Namen.
Für das Löschen einer voll funktionsfähigen HD allerdings sind alle drei
Tools genau gleich gut geeignet.
Hat man allerdings ein teildefekte HD und will auf der wenigstens die
noch schreibbaren Bereiche löschen, dann muss die Wahl zwingend auf
ddrescue fallen, denn da bricht dd_rescue genauso beim ersten
Schreibfehler ab wie dd.
Noch sehr viel sicherer ist in diesem Fall allerdings: Schraubenzieher
und Hammer...
Bei der Variante gibt es keine Möglichkeit, abzubrechen und an derselben
Stelle bequem fortzufahren.
Nach meiner Erfahrung hängt die Übertragungsgeschwindigkeit sehr von der
gewählten Blockgröße (bs) ab. Damit müsstest Du herumspielen.
● J-A V. schrieb:> Ich bekomme hier an USB Löschraten um die 33MB/sek hin,> an SATA nicht wesentlich mehr.
1.Mal nachgesehen was der GENAUE HD-Typ überhaupt leistet? Eine 5400er
Platte ist an einem P75 kein D-Zug.
2.NUR eine DATEI mit Nullen schreiben garantiert noch nicht, daß sich
kein Virus auf dem REST des Datenträgers befindet. Deshalb erbarmungslos
/dev/sdx komplett (ohne1) überschreiben und später neu partitionieren.
3.Statt Zufallszahlen alles Nullen schreiben kann später den Vorteil
haben, daß Images dieser Platte platzsparender komprimiert werden
können.
Jupp schrieb:> dd if=/dev/zero conv=noerror,notrunc,sync bs=65536 | pv >/dev/sda
Was soll denn noerror und sync bei dd bringen, wenn es von /dev/zero
liest und in eine Pipe schreibt?
Rolf M. schrieb:> Jupp schrieb:>> dd if=/dev/zero conv=noerror,notrunc,sync bs=65536 | pv >/dev/sda>> Was soll denn noerror und sync bei dd bringen, wenn es von /dev/zero> liest und in eine Pipe schreibt?
Wenn ich's mir recht überlege, bringt dd bei dieser Kommandozeile
eigentlich überhaupt nichts mehr. Eigentlich kannst du dir, wenn du es
so machst, dd also auch gleich ganz schenken und ein
1
pv < /dev/zero > /dev/sda
draus machen. Ich würde also sagen:
Jupp schrieb:> Mach es so. Genau so.
... nicht!
Übrigens hat dd zwar keine Verlaufsanzeige, aber die aktuelle Position
kann man sich trotzdem ausgeben lassen, indem man ihm ein SIGUSR1
schickt.
Peter M. schrieb:> Bei der Variante gibt es keine Möglichkeit, abzubrechen und an derselben> Stelle bequem fortzufahren.
Abbrechen kann man jederzeit, und es ist nicht erforderlich, an exakt
der selben Stelle weiterzumachen. Wenn man ein paar Bytes zweimal
ausnullt, passiert nix schlimmes.
Peter M. schrieb:> Bei der Variante gibt es keine Möglichkeit, abzubrechen und an derselben> Stelle bequem fortzufahren.
Lässt sich abbrechen, man sieht wieviel schon geschrieben wurde. Dort
kann man fortsetzen.
> Nach meiner Erfahrung hängt die Übertragungsgeschwindigkeit sehr von der> gewählten Blockgröße (bs) ab. Damit müsstest Du herumspielen.
Die o.g. bs ist Ergebnis vieler, vieler praktischer Tests. Theoretisch
gibt es "bessere" Werte, praktisch bewirkt die angegebene bs bei nahezu
allen Plattentypen Schreibraten am oberen Limit, unabhängig von
Cache-Strategie, Größe und zig weiteren Faktoren. Theorie und Praxis
gehen hier (warum auch immer) weit auseinander.
Rolf M. schrieb:> Wenn ich's mir recht überlege, bringt dd bei dieser Kommandozeile> eigentlich überhaupt nichts mehr.
Unfug. RTFM.
> Jupp schrieb:>> Mach es so. Genau so.>... nicht!
Weil du das sagst? Ich plätte seit Ewigkeiten Platten genau so, bei
nahezu allen Plattentypen mit Schreibraten am oberen Limit.
Ob die Platte nun 4MB oder 16MB cache hat, mach bei 1MB blocksize kaum
einen Unterschied. Der Overhead, 16 Blöcke zu schreiben, ist kaum
messbar. Schreibst du aber 1k-Blöcke, brauchst du davon 16384 Stück, das
reisst die Schreibgeschwindigkeit runter.
Rolf M. schrieb:> Was soll denn noerror und sync bei dd bringen, wenn es von /dev/zero> liest und in eine Pipe schreibt?
noerror verhindert das Abbrechen des Schreibvorgangs z.B. bei defekten
Sektoren. In Verbindung mit notrunc & sync zwingt das manche
Plattenfirmware dazu, sich etwas intensiver als im Normalbetrieb um
Ersatz für defekte Sektoren zu bemühen ;)
Jupp schrieb:> Ersatz für defekte Sektoren
Der Händler der Wahl verschickt auch neue Platten, der beste Ersatz.
Für mich ist das ein No-Go, eine Platte zu verwenden, die schonmal
rumzickte.
//edit: Achja, bevor ich so eine Platte wegschmeisse, geh ich da mit
schwerem Werkzeug ran und dann ab in den Schrott, geht viel schneller,
als Defekte Sektoren versuchen zu überschreiben...
Vorschlaghammer, Flex, Mikrowelle, kam alles schon zum Einsatz.
Nils S. schrieb:> Für mich ist das ein No-Go, eine Platte zu verwenden, die schonmal> rumzickte.
Für mich auch. Aber hier gings doch um dd, nicht um gute oder schlechte
Händler (was für mich persönlich sowieso nicht relevant ist).
Jupp schrieb:> nicht um gute oder schlechte> Händler
Mir gings darum auch nicht. Die Option, defekte Sektoren zu Ersetzen und
dem mit trunc+sync nachzuhelfen, hörte sich danach an, jede Platte um
jeden Preis weiterverwenden zu wollen.
Ich meinte damit "Ersatz für defekte Sektoren beschafft der Händler".
● J-A V. schrieb:> Ich lasse erstmal die diversen Empfehlungen wirken ;)
Vergess dabei die Kühlung der Platten nicht, wenn du stundenlang drauf
rumschreiben lässt. 1500 Betriebsstunden ist ja fast wie neu. Nach so
einer Tortour ohne Kühlung kann es dann schnell ein Fall für die Tonne
sein.
Peter II schrieb:> ● J-A V. schrieb:>> dd if=/dev/zero of=xx.txt bs=1M>> also schreibt du in eine Datei? Festplatten löscht man in dem man auf> das Device schreibt>> dd if=/dev/zero of=/dev/sda1 bs=1M
Genau: auf das Device, nicht die Partition:
dd if=/dev/zero of=/dev/sda bs=1M
● J-A V. schrieb:> Peter II schrieb:>> ● J-A V. schrieb:>>> ich lasse das in Dateien schreiben, die auf der Zielplatte landen.>>>> und warum? ein Dateisystem braucht man hier nicht und macht die ganze>> Sache langsamer.>> und bei Unterbrechungen?> (Stromausfall etc)>> -alles neu von vorne?
Ja. Meine Güte, es geht hier doch um das einmalige Nullen von Disks,
oder? Wie oft hast Du denn Stromausfälle?
Jupp schrieb:> Rolf M. schrieb:>> Was soll denn noerror und sync bei dd bringen, wenn es von /dev/zero>> liest und in eine Pipe schreibt?>> noerror verhindert das Abbrechen des Schreibvorgangs z.B. bei defekten> Sektoren.
Das bringt nur nichts, da dd gar nicht ins Device schreibt, sondern in
eine Pipe! Sofern die Pipe also nicht gerade defekten Sektoren bekommt,
ist dieser Parameter nutzlos, wenn du die Ausgabe von dd über Pipe an
pv weiterleitest. Und das gilt für alles andere, was dd normalerweise
macht, auch.
> In Verbindung mit notrunc & sync zwingt das manche> Plattenfirmware dazu, sich etwas intensiver als im Normalbetrieb um> Ersatz für defekte Sektoren zu bemühen ;)
Aber nur, wenn dd überhaupt auf die Platte zugreift und nicht nur auf
eine Pipe.
Jupp schrieb:>> Jupp schrieb:>>> Mach es so. Genau so.>>... nicht!>> Weil du das sagst?
Nein, sondern weil du halt nicht bedacht hast, dass deine Kommandozeile
den Nutzen von dd geschickt umgeht.
> Ich plätte seit Ewigkeiten Platten genau so, bei nahezu allen> Plattentypen mit Schreibraten am oberen Limit.
Es ist ja nicht so, dass es gar nicht funktionieren würde. Aber so wie
du es machst, bringt dd leider gar nichts mehr.
Rolf M. schrieb:> Es ist ja nicht so, dass es gar nicht funktionieren würde. Aber so wie> du es machst, bringt dd leider gar nichts mehr.
Na dann mache ich seit Jahren und manchmal dutzenden Platten in der
Woche was falsch. Is klar. Komisch nur, das dd, in genau dieser Art
angewendet, genau das macht, was es soll und wozu es aufgefordert
wird. Aber sicher willst du das auch wieder besser wissen.
Ich werde jetzt keine Romane schreiben, nur soviel: Nimm dir einen
Stapel Platten und probiere es aus.
Bernd K. schrieb:> Doch hat es: einfach status=progress als weiteren Parameter angeben.
Manpage ganz lesen hätte mir schon einige Male ddrescue installieren
erspart. Das kam oft nur wegen der Fortschrittsanzeige.
Sheeva P. schrieb:> Wie oft hast Du denn Stromausfälle?Sheeva P. schrieb:> Meine Güte
ja meine Güte, Sheeva wieder...
Es geht ja nicht nur um Stromausfälle.
Die Praxis ist eben doch immer mal anders als die Theorie.
Das schrieb ich oben aber schon.
Nils S. schrieb:> Bernd K. schrieb:>> Doch hat es: einfach status=progress als weiteren Parameter angeben.>> Manpage ganz lesen hätte mir schon einige Male ddrescue installieren> erspart. Das kam oft nur wegen der Fortschrittsanzeige.
Das ist noch relativ neu, das gibt's "erst" seid 8.24, das kam Mitte
2015.
Und dann muss es ja auch noch den weg in deine Distri finden...
Aber ja, das ist genau das was man ständig will :)
Jupp schrieb:> Komisch nur, das dd, in genau dieser Art> angewendet, genau das macht, was es soll und wozu es aufgefordert> wird. Aber sicher willst du das auch wieder besser wissen.
Da du offenbar gar nicht erst versuchen willst zu verstehen, wie das mit
den Pipes funktioniert und warum daher das von dir genannte Kommando
Blödsinn ist, hat es eigentlich keinen Zweck, weiter zu diskutieren.
> Ich werde jetzt keine Romane schreiben, nur soviel: Nimm dir einen> Stapel Platten und probiere es aus.
Ich hab ja schon geschrieben, dass es prinzipiell funktioniert - nur
nicht so, wie du glaubst. Das hast du aber auch ignoriert. Mach es
einfach weiter so - schaden tut's ja nicht, "ignorance is a bliss" und
so ...
Noch so am Rande:
Jupp schrieb:> Rolf M. schrieb:>> Wenn ich's mir recht überlege, bringt dd bei dieser Kommandozeile>> eigentlich überhaupt nichts mehr.>> Unfug.Rolf M. schrieb:> Eigentlich kannst du dir, wenn du es so machst, dd also auch gleich ganz> schenken und ein> pv < /dev/zero > /dev/sda> draus machen.Jupp schrieb:> RTFM.
Nun rate mal, was ich gerade in der man-Page von pv gefunden habe:
● J-A V. schrieb:> Da ich einen Rechner z.B. nicht gerne unbeaufsichtigt> und auch nicht über Nacht laufen lasse,> suche ich eine Möglichkeit, eine Platte in mehreren "Sitzungen"> nach und nach zu überschreiben.>> eine Fortschrittsanzeige für sowas wäre auch gut.
Du hast also nicht einmal in die Manpage von dd(1) geschaut. Dann
hättest Du die entsprechenden Optionen dafür nämlich schon gefunden.
● J-A V. schrieb:> Sheeva P. schrieb:>> Wie oft hast Du denn Stromausfälle?>> Sheeva P. schrieb:>> Meine Güte>> ja meine Güte, Sheeva wieder...>> Es geht ja nicht nur um Stromausfälle.
Sondern? Was gibt es denn noch, das so ein Ausnullen unterbrechen
könnte?
> Die Praxis ist eben doch immer mal anders als die Theorie.
Ja, und hier geht es um das popelige Ausnullen von Disks. Das ist ja
wohl wirklich keine Raketenwissenschaft.
> Das schrieb ich oben aber schon.
Jedenfalls lese ich Deine Beiträge aufmerksamer als Du die Manpages der
Werkzeuge, nach denen Du hier fragst. :-)
Hi
Sheeva P. schrieb:> nicht einmal in die Manpage von dd(1) geschaut.
Nunja, mir wäre diese Vortschrittsanzeigemöglichkeit auch nicht bekannt
gewesen.
Einzig, die Methode mit
Rolf M. schrieb:> $ kill -USR1 $!
wäre mir aus meiner Vergangenheit aus bekannt gewesen (und ich hätte
danach im WWW trotzdem suchen müssen, wäre wohl bei ubuntuusers.de
gelandet) und somit hätte ich die man-page mit Sicherheit nicht erneut
angeschaut, da mir bekannt ist, daß 'dd' Das 'nicht drauf hat' ... ok,
inzwischen wohl Vergangenheit, aber liest Du Dir zu jedem Quatsch, Den
Du relativ häufig benutzt, die Unterlagen jedes Mal durch?
Die Fortschrittsanzeige hat aber auch bei Ubuntuusers Einzug erhalten:
https://wiki.ubuntuusers.de/dd/#Fortschrittsanzeige
... aber auch dort hätte ich nach dem kill-Aufruf gesucht (den ich
bereits kannte), als nachzuforschen, ob irgend wer irgend wo irgend was
irgend wie geändert hat.
Gott sei Dank führen aber viele Wege nach Rom - konsequent wäre gewesen,
die kill-Variante bei dieser Änderung weg-zu-optimieren ;)
MfG
Patrick J. schrieb:> liest Du Dir zu jedem Quatsch, Den> Du relativ häufig benutzt, die Unterlagen jedes Mal durch?
Nein. Aber wenn mir eine naheliegende Funktionalität fehlt, die ich
gerade haben möchte, dann schon. Und bevor ich ein ganzes Forum mit
meiner Frage aufscheuche, auch -- schon aus Respekt vor den anderen
Nutzern.
Sheeva P. schrieb:> Ja. Meine Güte, es geht hier doch um das einmalige Nullen von Disks,> oder? Wie oft hast Du denn Stromausfälle?
Ich glaube, der desinfector wechselt im Tagesverlauf einfach die
Standorte, wollte uns das aber nicht auf die Nase binden.
Da kann es sein, dass man den Löschvorgang abbrechen muss.
Das liegt doch auf der Hand, daß man sich so organisiert, wenn man so
viele Platten löschen muss.
Rolf M. schrieb:> Peter M. schrieb:>> Bei der Variante gibt es keine Möglichkeit, abzubrechen und an derselben>> Stelle bequem fortzufahren.>> Abbrechen kann man jederzeit, und es ist nicht erforderlich, an exakt> der selben Stelle weiterzumachen. Wenn man ein paar Bytes zweimal> ausnullt, passiert nix schlimmes.
Natürlich geht es auch so.
Ich bin aber ein bequemer Mensch.
Nach dem Abbruch rufe ich einfach meinen Ausgangsbefehl über die Shell
wieder auf. Und da ich immer ein logfile schreiben lasse, holt sich
ddrescue die Information aus dem logfile, wo es weiter machen soll.
Ich muss also weder nachdenken, noch rechnen, das gefällt mir!
Rolf M. schrieb:> Was soll denn noerror und sync bei dd bringen, wenn es von /dev/zero> liest und in eine Pipe schreibt?
Danke für den Hinweis, dass die Parameter so sinnvoll sind wie
Mobilat-Salbe bei der Bundeswehr, war mir beim Drüberlesen gar nicht
aufgefallen!
Sheeva P. schrieb:> Und bevor ich ein ganzes Forum mit> meiner Frage aufscheuche, auch -- schon aus Respekt vor den anderen> Nutzern.
wir sind alles mündige Bürger...
das muss ja jeder selbst wissen, ob man sich aufscheuchen lässt :-)
Peter M. schrieb:> Ich glaube, der desinfector wechselt im Tagesverlauf einfach die> Standorte, wollte uns das aber nicht auf die Nase binden.>> Da kann es sein, dass man den Löschvorgang abbrechen muss.
In der Manpage steht auch dafür die passende Lösung. ;-)
Der Mensch ist eigentlich dafür bekannt, dass er Werkzeug benutzt.
Warum sich mit sowas rumquälen.
Au der c't CD ist dafür das dc3dd drauf.
Von Paragon gibt es das WipeDisk.
Und die HD-Hersteller haben sowas oft in ihrer Diagnose-Soft.
Wenn man die privat nutzen will, reicht doch nur neu partitionieren.
Für einen gewerblichen Verkauf reicht aber das Nullen sowieso nicht aus.
michael_ schrieb:> Der Mensch ist eigentlich dafür bekannt, dass er Werkzeug benutzt.
Paßt doch: dd(1) ist ein Werkzeug, Manpages sind auch Werkzeuge.
> Warum sich mit sowas rumquälen.
Wer "quält" sich denn?
> Au der c't CD ist dafür das dc3dd drauf.
Das ist auch nur eine gepatchte Version des bereits erwähnten dd(1) --
und die Manpage müßte man auch da lesen.
> Von Paragon gibt es das WipeDisk.
Das ist aber ein Windows-Programm, oder?
> Für einen gewerblichen Verkauf reicht aber das Nullen sowieso nicht aus.
Dafür bieten viele Linux-Distributionen spezielle Programme wie shred(1)
und sfill(1) (im Paket secure-delete) an -- welche die Festplatten nach
verschiedenen Algorithmen und Standards wie der Gutmann-Methode oder der
Richtlinie DoD 5220.22-M des us-amerikanischen Verteidigungsministeriums
löschen können.
Noch höhere Sicherheit bietet meines Wissens lediglich ein Erhitzen der
Platter über ihre Curie-Temperatur. Aber für Festplatten, die verkauft
werden sollen, fällt diese Lösung aus ökonomischen Gründen aus. ;-)
Daniel A. schrieb:> Hast du mit df nachgeschaut, ob die Platte sich auch tatsächlich> auffüllt? Ich glaube zwar, dass Linux noch nicht prüft, ob ein ganzer> block ausgenullt ist, aber wer weiss, sparse files sind möglich.
Da verwende ich anstatt /dev/null irgend ein mal runtergeladenes
ISO-Image (also ohnehin öffentlich zugängliche Daten als möglichst
Grosse Datei).
/dev/random wurde noch nicht erwähnt. Dieses device hat aber selten
den Durchsatz von Massespeicher Schnittstellen und wirkt entsprechend
als zuverlässige Bremse.
michael_ schrieb:> Für einen gewerblichen Verkauf reicht aber das Nullen sowieso nicht aus.
Warum reicht Nullen nicht aus?
Was ist denn für einen "gewerblichen Verkauf" nötig?
Peter M. schrieb:> michael_ schrieb:>> Für einen gewerblichen Verkauf reicht aber das Nullen sowieso nicht aus.>> Warum reicht Nullen nicht aus?> Was ist denn für einen "gewerblichen Verkauf" nötig?
Das soll sich wohl darauf beziehen, dass ein professioneller
forensischer Datenretter theoretisch die Disks der "genullten"
Festplatte ausbauen und dann mit Labor-Equipment die Daten zumindest
teilweise rekonstruieren könnte. Weshalb es früher mal die Ansicht gab,
alte Festplatte mindestens soundsoviel mal hintereinander mit
Zufallszahlen oder sowas zu überschreiben, damit man da nichts mehr
rekonstruieren kann.
Allerdings habe ich schon vor ein paar Jahren (ich glaube in der c't
oder auf heise) diesbezüglich die Aussage genau so eines professionellen
Datenretters gelesen, dass das zwar anno dazumal eine Berechtigung
gehabt haben mag, als die Festplatten noch geringe Speicherdichten
hatten, bei den heutigen Festplatten mit ihren extrem hohen
Speicherdichten aber im Grunde unnötig ist, und schon ein einfaches
Nullen im Grunde ausreicht.
Ich persönlich würde heutzutage, wenn ich mal ganz auf Nummer sicher
gehen wollte, maximal einmal mit
Joachim S. schrieb:> Weshalb es früher mal die Ansicht gab,> alte Festplatte mindestens soundsoviel mal hintereinander mit
einige Sicherheitsstufen https://www.bsi.bund.de/
Joachim S. schrieb:> bei den heutigen Festplatten mit ihren extrem hohen> Speicherdichten aber im Grunde unnötig ist
Zusammenfassend: mehrfaches Überschreiben bringt zwar nichts, schadet
aber auch nicht, also wenn's der eigenen Beruhigung dient...
Was anderes wäre es, wenn die Atomcodes der USA auf der Festplatte wären
und sich die Geheimdienste dafür interessieren würden, aber das betrifft
wohl nur wenige Forumsteilnehmer.
Georg
Georg schrieb:> Was anderes wäre es, wenn die Atomcodes der USA auf der Festplatte wären> und sich die Geheimdienste dafür interessieren würden, aber das betrifft> wohl nur wenige Forumsteilnehmer.
Die Atomcodes sind 00000000¹. Das eignet sich hervorragend um Platten zu
löschen.
Wenn die Spur auf einer Platte nach dem Schreiben immer noch das zuvor
geschriebene ebenfalls wiedergeben könnte dann würden die Hersteller
dies schon längst bemerkt haben und den Effekt nutzen um Platten mit
noch höherer Speicherdichte bauen, so lange bis jedes Fitzelchen Fläche
auf dem Datenträger wirklich 100% ausgenutzt würde und kein Platz mehr
für alte Daten bliebe.
_________________
¹)
https://www.heise.de/security/meldung/00000000-Passwort-fuer-US-Atomraketen-2060077.html
Joachim S. schrieb:> Allerdings habe ich schon vor ein paar Jahren (ich glaube in der c't> oder auf heise) diesbezüglich die Aussage genau so eines professionellen> Datenretters gelesen, dass das zwar anno dazumal eine Berechtigung> gehabt haben mag, als die Festplatten noch geringe Speicherdichten> hatten, bei den heutigen Festplatten mit ihren extrem hohen> Speicherdichten aber im Grunde unnötig ist, und schon ein einfaches> Nullen im Grunde ausreicht.
Genau das habe ich auch in der c't gelesen, ich glaube, dass war eine
Aussage von Kroll Ontrack und genau deswegen habe ich den Gast Michael
gefragt, der es natürlich nicht begründen konnte.
Nullen heißt aber nicht, eine lange Datei in's Dateisystem schreiben, so
wie es desinfector beschrieben hat.
Nullen heißt, die Festplatte komplett zu löschen.
Wenn jetzt jemand sagt, es müsse der ATA-Befehl Secure Erase genutzt
werden, ist das Stoff für einen Extrafaden.
Extremparanoiker nutzen das Gutmann'sche Verfahren des 35-maligen
Überschreiben, was bei heutigen Platten nicht mehr notwendig scheint.
https://en.wikipedia.org/wiki/Gutmann_method
Sheeva P. schrieb:>> Au der c't CD ist dafür das dc3dd drauf.>> Das ist auch nur eine gepatchte Version des bereits erwähnten dd(1) --> und die Manpage müßte man auch da lesen.
Ja, aber schon praktisch angepasst.
Der TO will eine Platte mit Partitionen löschen, was ja schon Unsinn
ist.
Den MBR und unpartitionierte Bereiche erreicht man damit nicht.
Sheeva P. schrieb:>> Von Paragon gibt es das WipeDisk.>> Das ist aber ein Windows-Programm, oder?
Entschuldigung, bei Paragon ist das Disk Wiper.
Aber auch enthalten in der HD Suite.
Was stört dich an einem WIN-Programm?
Peter M. schrieb:> michael_ schrieb:>> Für einen gewerblichen Verkauf reicht aber das Nullen sowieso nicht aus.>> Warum reicht Nullen nicht aus?> Was ist denn für einen "gewerblichen Verkauf" nötig?
War in einem Artikel der c't dargelegt.
Eigentlich für einen Privatmann unerreichbar.
michael_ schrieb:> War in einem Artikel der c't dargelegt.> Eigentlich für einen Privatmann unerreichbar.
Ich bin Privatmann und c't-Abonnent seit dem Jahre 2000.
Sei so lieb und nenn' mir den Artikel.
Ich lerne gerne dazu!
Selbst wenn ich die Zeitung nicht abonniert hätte, kann ich Dir aus dem
Kopf 3 Bibliotheken in Hannover nennen, die die c't abonniert haben:
Stadtbibliothek
Technische Informationsbibliothek
Fachhochschule Hannover (wurde verbal aufgewertet als "Hochschule
Hannover")
Und es gibt definitiv noch mehr, aber das sind meine üblichen
Verdächtigen.
Der Online-Artikelverkauf steht übrigens auch "Privatleuten" im
Heise-Verlag zur Verfügung, dafür muss man nicht die
"Nerd-Club-Mitgliedskarte" besitzen.
Auch der kleine Edeka-Markt in der Südstadt verkauft die "unerreichbare"
c't, er archiviert sie allerdings nicht.
Wohnst Du nicht in Deutschland?
Peter M. schrieb:> Ich bin Privatmann und c't-Abonnent seit dem Jahre 2000.> Sei so lieb und nenn' mir den Artikel.> Ich lerne gerne dazu!
Ich bin zu faul, das letzte halbe Jahr für dich nachzuschlagen.
Aber länger ist es nicht her.
Gut, ein 3/4 Jahr???
Tu mal selber blättern.
Автомат К. schrieb:> ● J-A V. schrieb:>> Ich lasse erstmal die diversen Empfehlungen wirken ;)>> Übersetzung: Du hast von all dem nicht viel bis rein gar nix verstanden> ;)
Ich hab zumindest schon mal verstanden,
dass es für viele OK ist, nicht so wirklich die Übersicht zu behalten.
Peter M. schrieb:> Sei so lieb und nenn' mir den Artikel.
Ich bin nicht lieb, aber ein Gutmensch, der für dich geblättert hat.
Also setze mal eine Lesebrille auf und schau rein:
c't 8/2016 S. 136 Kasten auf S. 137 ist interessant (DIN 66399)
c't 13/2016 mehrere Artikel ab S. 84
Unter WIN gibt es das Tool Diskpart.
werdenn schrieb:> Warum nehmt Ihr eigentlich nicht das einfache dd if=/dev/zero> of=/dev/sda?
U.a. weil J-V Angst hat, dass der Strom ausfällt, und dass daher das
Löschen einmal in 500 Jahren nicht funktioniert.
Georg
Georg schrieb:> Angst hat, dass der Strom ausfällt
Angst nicht, aber es gibt genügend andere Gründe.
Ich lasse eine Rechner auch nicht gerne in Abwesenheit laufen.
auch nicht nachts. Momentan steht die Kiste nämlich in der Schlafbude.
wenn ich merke, dass das alles länger dauert, als ich es mag,
kann ich halt am nächsten Tag weiter machen und muss nicht wieder
von vorne anfangen, wie es bei so einigen anderen Tipps nötig wäre.
Und um das zweite Teilproblem zu adressieren:
Wenn man eine Vorstellung von der Geschwindigkeit des Vorgangs nach
einem Test(an)lauf hat kann man das ja auch Abschnittsweise in Angriff
nehmen.
Bzw dort weiter machen wo man den Vorgang abrach, im verbose-mode zeigt
es ja dauernd an wo er sich grad befindet, vom letzten bearb. Block aus
könnte man ja dann wieder starten. (Zu beachten ist aber wirklich das
man ein Muster angibt sonst dauert das noch länger wenn es verschiedene
hintereindader durchlaufen läßt ..., random als opt. gibt es ebenfalls)
da gibts auch was dazu, ansonten hilft $man badblocks
https://superuser.com/questions/692912/is-there-a-way-to-restart-badblocks
---
Würde so einen Ansatz für geeigneter halten.
michael_ schrieb:> Sheeva P. schrieb:>>> Au der c't CD ist dafür das dc3dd drauf.>>>> Das ist auch nur eine gepatchte Version des bereits erwähnten dd(1) -->> und die Manpage müßte man auch da lesen.>> Ja, aber schon praktisch angepasst.> Der TO will eine Platte mit Partitionen löschen, was ja schon Unsinn> ist.> Den MBR und unpartitionierte Bereiche erreicht man damit nicht.
Doch, natürlich erreicht man die. Aber dazu muß man die Platte selbst
(zB. /dev/sda) mit dd(1) behandeln, und nicht nur eine Partition
(/dev/sda1).
> Sheeva P. schrieb:>> Das ist aber ein Windows-Programm, oder?>> Was stört dich an einem WIN-Programm?
Daß der TO ausdrücklich sagt, daß er Linux benutzen will. Mir persönlich
ist das herzlich egal -- ich habe zwar kein Windows, kann aber mit
meinem Linux und seinen Werkzeugen gut genug umgehen, um das vom TO
Gewünschte umzusetzen -- und ansonsten würde ich in meine Manpages
schauen. ;-)
● J-A V. schrieb:> wenn ich merke, dass das alles länger dauert, als ich es mag,> kann ich halt am nächsten Tag weiter machen und muss nicht wieder> von vorne anfangen
Dann setz den Rechner doch einfach in den Hibernate bevor Du schlafen
gehst. Das tut doch dem dd keinen Abbruch.
michael_ schrieb:>> c't 8/2016 S. 136 Kasten auf S. 137 ist interessant (DIN 66399)
Danke für den Hinweis, doch da sind die Schutzklassen zur Vernichtung
von Datenträgern nach DIN 66399 aufgeführt.
Du schriebst aber:
michael_ schrieb:> Für einen gewerblichen Verkauf reicht aber das Nullen sowieso nicht aus.
Unter "gewerblichen Verkauf" habe ich den Verkauf an einen
Weiterverwender, keinen Entsorger verstanden!
> c't 13/2016 mehrere Artikel ab S. 84>> Unter WIN gibt es das Tool Diskpart.
Mein Windows hat kein Diskpart, das gab es erst später.
Hier ist der Artikel bei Heise:
https://www.heise.de/security/meldung/Sicheres-Loeschen-Einmal-ueberschreiben-genuegt-198816.html
Das ist ein tolles Beispiel wie man mit geschickter Formulierung einen
falschen Eindruck erzeugen kann:
Wenn ich sage das ich mit 56%iger Wahrscheinlichkeit Daten auf einer
einmal überschriebenen Festplatte wieder herstellen kann, hört sich das
ja gar nicht mal so schlecht an... Das es sich dabei um den Zustand nur
eines Bits handelt und damit die Chance nur ein Byte korrekt wieder
herzustellen bei unter 1% liegt macht natürlich deutlich weniger her.
Am einfachsten ist es, Du wirfst für jedes Bit eine Münze. Damit kannst
Du mit 50%iger Wahrscheinlichkeit dessen Wert wiederherstellen. Die
Verbundwahrscheinlichkeit für ein korrektes Byte liegt dann bei 0,4%.
wollte jetzt hier in der Firma an einem Ubuntu 12.04 Rechner
mit
dd if=/dev/zero of=sdb bs=1M
eine 80er Platte löschen.
Ergebnis:
Es schreibt mir sda3 (Home-Partition) voll.
was blicke ich da nicht?
der Baum sieht hier so aus:
sda 8:0 0 149,1G 0 disk
├─sda1 8:1 0 1,9G 0 part [SWAP]
├─sda2 8:2 0 37,3G 0 part /
└─sda3 8:3 0 109,9G 0 part /home
sdb 8:16 0 80,0G 0 disk
● J-A V. schrieb:> dd if=/dev/zero of=sdb bs=1M
Wo auch immer du das Kommando ausgeführt hast liegt jetzt ne Datei mit
dem namen sdb.
if=/dev/zero
of=sdb
da fehlt wohl nen dev vorm sdb
● J-A V. schrieb:> wollte jetzt hier in der Firma an einem Ubuntu 12.04 Rechner>> mit>> dd if=/dev/zero of=sdb bs=1M>> eine 80er Platte löschen.>> Ergebnis:> Es schreibt mir sda3 (Home-Partition) voll.>> was blicke ich da nicht?>
Du hast dir wohl mit "of=sdb" eine Datei namens sdb im dem aufrufenden
Verzeichnis generiert.
● J-A V. schrieb:> Datum: 21.03.2017 15:45
^^^^^
--------------------|||||
> ich bin noch nicht so klar am frühen morgen ;)
...ich hätt ja jetzt was über das laue Studentenleben gesagt, aber da
kam irgendwo noch das Wort "Firma" vor.
Jetzt bin ich verwirrt :D
● J-A V. schrieb:> ich guck mir bei jedem Mal die Baumstruktur mit "lsblk" an.> Soviel Zeit muss sein.
Merke:
Mit dd kannst du dir so richtig selbst ins Knie schießen.
Mit deinem falschen Aufruf "of=sdb" warst du schon nah dran aber es ging
nochmal gut aus.
Die dd-Parameter sind doppelt und dreifach zu prüfen, nicht nur ein
lsblk.
nö wieso?
ich wollte doch sdb in der Tat überschreiben.
Nur übersah ich den Syntax-Fehler mit dem /dev/sdb
und ich wunderte mich über den Datei-Klotz in sda3
das kann ich schon noch überblicken,
dass ich das System nicht zergurke.
Und selbst wenn, dann hätte ich noch einen Platten-Klon
des Firmenrechners gehabt. Da ist kaum was drauf,
nur was zum Schreiben und DaBlä laden/drucken etc.
● J-A V. schrieb:> nö wieso?
Weil dd kein Netz oder doppelten Boden hat und deinen Befehl einfach
stumpf ausführt, auch wenn er falsch formuliert ist.
In deinem Fall hat das nicht gestört: hast anstelle deine Festplatte zu
Nullen eben eine dicke Datei mit vielen Nullen angelegt.
Alles nochmal gut gegangen.
Beim nächsten Typo überbügelst du dir vielleicht die Systempartition
oder deine Urlaubsfotos der letzten 10 Jahre weil du "sdx" statt "sdxy"
schreibst.
dd ist ein Befehl den man einfach sorgfältig benutzen sollte.
Ähnlich wie rm kann er richtigen Schaden anrichten.
Deswegen ist dd nicht böse oder schlecht, setzt aber beim Anwender etwas
mehr Sorgfalt vorraus.
● J-A V. schrieb:> Syntax-Fehler mit dem /dev/sdb
Das ist kein Syntax-Fehler sondern ein gültiger dd Aufruf!
Deswegen passieren bei dd auch so gerne Fehler.
Le X. schrieb:> Beim nächsten Typo überbügelst du dir vielleicht die Systempartition> oder deine Urlaubsfotos der letzten 10 Jahre weil du "sdx" statt "sdxy"> schreibst.
ja wenn ich das mit einem Rechner mache würde,
wo solche Fotos als Einziges überhaupt drauf sind,
darft du mich erschiessen, so blöd war nicht mal meine Omma.
● J-A V. schrieb:> ja wenn ich das mit einem Rechner mache würde,> wo solche Fotos als Einziges überhaupt drauf sind,> darft du mich erschiessen, so blöd war nicht mal meine Omma.
Ach VdH, das war ein gut gemeinter Rat. Manche Befehle verlangen eben
Konzentration und Sorgfalt und verzeihen keine Fehler.
Da gibts dann keine 2. Chance.
Das hat auch nichts mit Blödheit zu tun, ein Typo passiert jedem mal.
Solltest du wirklich gegen solch menschliche Fehler immun sein dann nehm
ich meinen Ratschlag zurück bzw. reiche ihn an die Normalsterblichen
Menschen weiter (so wie mir) denen manchmal Fehler passieren.
Fühl dich dann einfach nicht angesprochen.
● J-A V. schrieb:> das kann ich schon noch überblicken,● J-A V. schrieb:> so blöd war nicht mal meine Omma
Nachdem was man von dir im letzten Jahr, seit du auf deinem Linux-Trip
bist so liest bezweifle ich das zwar, aber du wirst schon wissen was du
tust.
● J-A V. schrieb:> darft du mich erschiessen, so blöd war nicht mal meine Omma.
Die vielleicht nicht, ich kenne sie ja nicht, aber tausende, oder eher
Millionen User schon. Die Foren sind voll von Hilferufen der Art "ich
habe meine Festplatte an ein falsches Netzteil angeschlossen" oder "ich
bin versehentlich mit dem Auto über mein Notebook gefahren", mit der
Frage "wie kann ich jetzt meine Urlaubsfotos auslesen?". Die Antwort mit
der Frage nach einem Backup kann man sich gleich sparen.
Georg
Georg schrieb:> Hilferufen der Art "ich> habe meine Festplatte an ein falsches Netzteil angeschlossen" oder "ich> bin versehentlich mit dem Auto über mein Notebook gefahren"
ist aber schon noch ziemlich was anderes als mein "Trip"
● J-A V. schrieb:>> bin versehentlich mit dem Auto über mein Notebook gefahren">> ist aber schon noch ziemlich was anderes als mein "Trip"
"ich hab versehentlich meine Familienbilder mit dd überbügelt, wie
kann ich die wieder herstellen?"
"wärst mal lieber stattdessen mit dem Auto drüber gefahren, dann gäbs
noch ne Chance."
Georg schrieb:> Die Foren sind voll von Hilferufen der Art "ich> habe meine Festplatte an ein falsches Netzteil angeschlossen" oder "ich> bin versehentlich mit dem Auto über mein Notebook gefahren", mit der> Frage "wie kann ich jetzt meine Urlaubsfotos auslesen?".
Oder du machst es wie meine Nachbarn. Erst lieb fragen, ob man die Daten
von der kaputten Festplatte kratzen kann, sie dann voller Freude auf den
Rechner kopieren.
Und den dann am nächsten Tag neu formatieren und installieren, weil er
voll war. ;-)
● J-A V. schrieb:> Trip würde ich das noch nicht nennen.> Ich kratz gerade mal an der Oberfläche.
Statt Dir einzelne Befehle aus dem Internet herauszusuchen und dann hier
zu fragen, wenn sie irgendwie doch nicht tun, was Du Dir wünschst,
könntest Du die Sache aber auch einfach mal richtig angehen. Zum
Beispiel das Buch [1] lesen und die vorhandene und meist mitinstallierte
Dokumentation (Man- und Infopages) benutzen. Das würde Dein Leben mit
Linux enorm vereinfachen und produktiver machen, und Du müßtest hier
auch keine Fragen mehr stellen, die Du Dir mit einem kurzen Blick in die
Manpage in wenigen Sekunden selbst hättest beantworten können.
[1] https://kofler.info/buecher/linux/
Sheeva P. schrieb:> und Du müßtest hier> auch keine Fragen mehr stellen,
ich stelle solche Fragen nicht nur für mich.
sondern damit das für andere auch findbar wird.
Und:
letztlich lebt ein Forum davon.
● J-A V. schrieb:> ich stelle solche Fragen nicht nur für mich.> sondern damit das für andere auch findbar wird.
Dann versteh ich nicht wieso du aufgrund meines Rates gleich in den
Rumpelstielzchen-Modus schalten musst.
Nachdem das eigentliche Thema geklärt war wollte ich nochmal hervorheben
dass Kommandos wie "dd", "rm" usw. mit großer Sorgfalt zu verwenden
sind.
Du selbst bist das beste Beispiel dass man das nicht oft genug erwähnen
kann.
Du hast nachweislich "dd" falsch aufgerufen, "dd" hat deinen Aufruf aber
nicht als Fehler erkannt sondern stumpf ausgeführt.
Und es war reines Glück dass nur eine große leere Datei angelegt wurde
und nichts Schlimmeres passiert ist.
Und anstelle zu kapieren wie nah du der Datenapokalypse warst kommst du
mit so lustigen Ausreden daher:
● J-A V. schrieb:> ja wenn ich das mit einem Rechner mache würde,> wo solche Fotos als Einziges überhaupt drauf sind,> darft du mich erschiessen, so blöd war nicht mal meine Omma.
Der Witz an "Bedienfehlern" ist ja dass man vorher nicht weiß dass man
sie macht. Sonst würde man sie ja nicht machen.
Meinst du ich denk mir auf Arbeit "Morgen ist ein wichtiges Release, da
mach ich ausnahmsweise mal keine Fehler und bau keine Bugs ein"?
Und genauso kann dir ein Fehler passieren wenn du an deinem Foto-Rechner
gerade deine 5 Festplatten nullst.
Sagen wir, es ist halb 12 Abends und bei der 5. Festplatte übernimmst du
versehentlich die Falsche Zeile aus der "lsblk"-Ausgabe.
Dann steht da auf einmal of=/dev/sdc" statt of=/dev/sdd und schon wars
das.
Und dein Backup stammt noch von vor der letzten Weltreise.
Fehler passieren nun mal und du weißt vorher nicht wann dir einer
passieren wird.
Deswegen muss man immer sorgfältig arbeiten besonders wenn man Tools
benutzt die keine Fehler verzeihen.
● J-A V. schrieb:> ich stelle solche Fragen nicht nur für mich.> sondern damit das für andere auch findbar wird.
So ein Unsinn. Du stellst solche Fragen, weil Du zu faul bist, Dich
richtig einzuarbeiten und die Dokumentation zu lesen. Deswegen sind
Deine Fragen kein Dienst an der Gemeinschaft, sondern ein Mißbrauch
ihrer Hilfsbereitschaft.
> letztlich lebt ein Forum davon.
Ein Forum lebt nicht von Fragen nach Dingen, die in der Dokumentation
stehen. Ein Forum lebt von Fragen nach Dingen, die nicht in der
Dokumentation stehen.
Sheeva P. schrieb:> Ein Forum lebt von Fragen nach Dingen, die nicht in der> Dokumentation stehen.
steht da auch dass das Schreiben in eine Datei
oder auf das Device keinen Unterschied in der Geschwindigkeit
darstellen?
das hatte ich jetzt aus 2 Rechnern so.
Sheeva P. schrieb:> So ein Unsinn.
ja, Du siehst vieles überheblich als Unsinn an.
● J-A V. schrieb:> Sheeva P. schrieb:>> Ein Forum lebt von Fragen nach Dingen, die nicht in der>> Dokumentation stehen.>> steht da auch dass das Schreiben in eine Datei> oder auf das Device keinen Unterschied in der Geschwindigkeit> darstellen?
Sowas muß nicht in der Dokumentation stehen, weil es sich jedem, der die
Dokumentation gelesen hat, schon von selbst erschließt. In beiden Fällen
geschieht weitestgehend dasselbe: es wird auf eine Festplatte
geschrieben. Weshalb sollte es dabei einen "Unterschied in der
Geschwindigkeit" geben?
> Sheeva P. schrieb:>> So ein Unsinn.>> ja, Du siehst vieles überheblich als Unsinn an.
So wie Du eine vernünftige Einarbeitung und die Benutzung der
Dokumentation? Als überheblich empfinde ich es eher, das beides zu
verweigern, stattdessen die Hilfsbereitschaft anderer Menschen zu
mißbrauchen und dann auch noch zu heucheln, es gehe dabei um einen
Dienst an der Allgemeinheit.
● J-A V. schrieb:> btw - es lässt sich alles, was hier gefragt wird anderweitig "erlesen"
Alle Fragen, die ich von Dir in diesem Forum zum Thema Linux gelesen
habe, hättest sich Dir entweder gar nicht gestellt, oder Du hättest sie
Dir selbst beantworten können -- wenn Du Dich bloß vernünftig
eingearbeitet hättest und die Dokumentation benutzt würdest.
> Das ist wirklich eine geniale Einstellung von Dir!
Danke, aber ich bin kein Genie. Ich hab auch nur die Dokumentation
gelesen.
Sheeva P. schrieb:> In beiden Fällen> geschieht weitestgehend dasselbe: es wird auf eine Festplatte> geschrieben. Weshalb sollte es dabei einen "Unterschied in der> Geschwindigkeit" geben?
weil sowas immer wieder gesagt wird:
Joachim S. schrieb:> Und wenn man die ganze Disk plattmachen will, dann sollte man> natürlichof=/dev/sd[a|b|c|whatever] benutzen - nur so macht man die Disk> tatsächlich platt, ausserdem> sollte es die Geschwindigkeit deutlich erhöhen.
● J-A V. schrieb:> Sheeva P. schrieb:>> In beiden Fällen>> geschieht weitestgehend dasselbe: es wird auf eine Festplatte>> geschrieben. Weshalb sollte es dabei einen "Unterschied in der>> Geschwindigkeit" geben?>> weil sowas immer wieder gesagt wird:>> Joachim S. schrieb:>> Und wenn man die ganze Disk plattmachen will, dann sollte man>> natürlichof=/dev/sd[a|b|c|whatever] benutzen - nur so macht man die Disk>> tatsächlich platt, ausserdem>> sollte es die Geschwindigkeit deutlich erhöhen.
Joachim S.' Aussagen zur Geschwindigkeit beziehen sich natürlich auf
seine Ausführungen zur Blockgröße -- was jeder gewußt und verstanden
hätte, der die Dokumentation gelesen hat. So zeigt sich wieder einmal,
wie fatal es ist, daß Du Dich statt einer seriösen Einarbeitung lieber
auf die Aussagen eines Forums verläßt, die Du dann weder verstehen noch
einordnen kannst.
Echt jetzt: daß ich und andere Dir den Rat geben, die vernünftig ins
Thema Linux einzuarbeiten und die Dokumentation zu benutzen, ist doch
nicht böse gemeint -- sondern im Gegenteil ein sehr sinnvoller und
vernünftiger Rat, der Dich vor Schäden schützen, Deine Arbeitseffizienz
mit und Deinen Spaß an Deinem Linux-System steigern soll. Probier das
doch mal aus. Du wirst schnell feststellen, daß die hervorragende
Dokumentation, die für Linux verfügbar ist, zu seinen stärksten
Vorteilen gehört.
● J-A V. schrieb:> Sheeva P. schrieb:>> In beiden Fällen>> geschieht weitestgehend dasselbe: es wird auf eine Festplatte>> geschrieben. Weshalb sollte es dabei einen "Unterschied in der>> Geschwindigkeit" geben?>>> weil sowas immer wieder gesagt wird:>> Joachim S. schrieb:>> Und wenn man die ganze Disk plattmachen will, dann sollte man>> natürlichof=/dev/sd[a|b|c|whatever] benutzen - nur so macht man die Disk>> tatsächlich platt, ausserdem>> sollte es die Geschwindigkeit deutlich erhöhen.
Naja dd kopiert Dateien,
es wird gelesen, ggf. etwas manipuliert und dann geschrieben.
Wenn man aufgrund des Umfangs die Geschwindigkeit des Ablaufs verbessern
will muss man an der Eingangangsseite gucken.
Aus dem permanenten blockweise lesen und schreiben in gleicher
Block-Größe könnte man ein einmaliges lesen machen in dem vorher die
Anzahl der Blöcke und Größe des Ziels ermittelt und entsprechende
parameter zum auffüllen setzt. Dann könnte sich der der Ablauf
beschleunigen.
----
padding/sync-option, auffüllen mit Nullen zur Blockgröße
An sicherem Plätzchen testen, zum Beispiel
$echo | dd bs=10k of=testfile conv=sync
$hexdump -C testfile
00000000 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
00002800
-----
Nicht weiter untersucht!
Aber bs kann lt. man auch > 1T werden.
seltener Nutzer schrieb:> Aber bs kann lt. man auch > 1T werden.
und du glaubst DADURCH wird's schneller?
weil ja erst das ganze file gelesen wind und dann geschrieben, statt das
irgendwie halbwegs parallel zu machen?
Dirk D. schrieb:> seltener Nutzer schrieb:>> Aber bs kann lt. man auch > 1T werden.>> und du glaubst DADURCH wird's schneller?>> weil ja erst das ganze file
Hi,
Das ganze INPUT-file besteht eg. aus einem einzelnen Byte.
Das auffüllen macht dd selber.
root@box:$echo "x" | dd bs=10k of=testfile conv=sync
0+1 records in
1+0 records out
10240 bytes (10 kB) copied, 0.00185283 s, 15.5 MB/s
root@box:$hexdump -C testfile
00000000 78 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|x...............|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
Der Unterschied sollte darin bestehen das nicht (hier als Bsp.) 10240
mal eg. /dev/zero herangezogen wird.
seltener Nutzer schrieb:> Aber bs kann lt. man auch > 1T werden.
Dann brauchst du aber auch > 1 TB RAM, damit das funktioniert.
Und es wird langsamer sein.
seltener Nutzer schrieb:> Naja dd kopiert Dateien,>> es wird gelesen, ggf. etwas manipuliert und dann geschrieben.> Wenn man aufgrund des Umfangs die Geschwindigkeit des Ablaufs verbessern> will muss man an der Eingangangsseite gucken.
Man muß auf beide Seiten schauen. Wenn die Ausgansseite saturiert ist,
dann helfen Optimierungen auf der Eingangsseite auch nichts mehr. Und in
dem hier diskutierten Fall, wo von einem schnellen Kernel-Pseudodevice
wie /dev/zero gelesen wird, spielt das ohnehin keine Rolle: der Kernel
und die notwendigen Kontext-Switches zum Transport der generierten Daten
in den Userspare wirst Du nicht beschleunigen können, und die
Zeitaufwände dafür sind im Verleich zur Schreibperformance der
Ausgangsfestplatte weitgehend vernachlässigbar. Der einzig sinnvolle
Ansatz zur Optimierung ist die Ausgangsseite.
Sheeva P. schrieb:> Sowas muß nicht in der Dokumentation stehen, weil es sich jedem, der die> Dokumentation gelesen hat, schon von selbst erschließt. In beiden Fällen> geschieht weitestgehend dasselbe: es wird auf eine Festplatte> geschrieben. Weshalb sollte es dabei einen "Unterschied in der> Geschwindigkeit" geben?
Es gibt einen Unterschied, ob man linear auf ein Gerät wegschreibt oder
"höher" auf Dateisystemebene in eine Datei schreibt.
Offensichtlich wird es dann, wenn das Dateisystem relativ voll und
fragmentiert ist und der Festplattenarm hin- und herfahren muss.
Das gilt natürlich nicht für eine SSD.
Jüngst hatte ich etwas von einer Art "Befehlssimulator" für Linux
gehört, der dann eventuell gefährliche Schreibbefehle abfängt und man
irgendwie sehen kann, was die Kommandozeileneingabe bewirkt hat.
Der Name ist mir leider entfallen.
Peter M. schrieb:> Es gibt einen Unterschied, ob man linear auf ein Gerät wegschreibt oder> "höher" auf Dateisystemebene in eine Datei schreibt.
Der Overhead durch das Dateisystem selbst ist weitgehend
vernachlässigbar, gerade für einzelne, große Dateien oder gar ganze
Festplatten. Bei vielen kleinen Dateien kann das eine Rolle spielen,
angesichts der Performanz und Effizienz moderner Rechner, Betriebs- und
Dateisysteme bleibt diese aber auch marginal. Nicht nur meß-, sondern
auch spürbare Auswirkungen hat das nach den mir bekannten Daten und
meinen eigenen Erfahrungen nur noch im Zusammenhang mit verschlüsselten
oder komprimierten Dateisystemen.
> Offensichtlich wird es dann, wenn das Dateisystem relativ voll und> fragmentiert ist und der Festplattenarm hin- und herfahren muss.> Das gilt natürlich nicht für eine SSD.
In der Praxis fragmentieren die meisten Linux-Dateisysteme wenig bis gar
nicht, und versuchen dennoch aufgetretene Fragmentierungen im
Hintergrund selbständig zu beheben. Mein mittlerweile acht Jahre altes
/-Dateisystem wird täglich intensiv genutzt, noch nie manuell
defragmentiert, und kommt aktuell auf einen Fragmentierungsgrad von ca.
5,5 Prozent.
In Abhängigkeit von Dateigrößen und der Größe von Dateisystemen und
ihrer Belegung kann in seltenen Fällen natürlich trotzdem eine
Fragmentierung auftreten, und in diesem seltenen Ausnahmefall ist das
Schreiben in das Dateisystem tatsächlich langsamer. Wobei in dem Falle
aber auch noch ein Dateisystempuffer dazwischen sitzt und die
Schreibzugriffe optimiert und neu ordnet, um die Bewegungen der
Plattenköpfe zu reduzieren.
> Jüngst hatte ich etwas von einer Art "Befehlssimulator" für Linux> gehört, der dann eventuell gefährliche Schreibbefehle abfängt und man> irgendwie sehen kann, was die Kommandozeileneingabe bewirkt hat.> Der Name ist mir leider entfallen.
Sowas kenne ich leider auch nicht, außer den Schaltern für interaktive
Modus von CLI-Programmen wie rm(1), cp(1) und Co -- aber das ist etwas
gänzlich anderes als ein Simulator, wie Du ihn beschreibst. Wenn Du den
wiederfindest, wäre ich daran aber sehr interessiert.
Peter M. schrieb:> Jüngst hatte ich etwas von einer Art "Befehlssimulator" für Linux> gehört, [...]
Daran wäre ich auch sehr interessiert.
Vor den meisten Dummheiten (cp, mv, rm) kann man sich schützen, indem
man konsequent billige Snapshots anlegt, wenn das Dateisystem sowas
unterstützt, wie z.B. bei ZFS. Hilft aber auch nicht, wenn man sich mit
dd gleich das gesamte Blockdevice wegschießt...
Sheeva P. schrieb:> Der Overhead durch das Dateisystem selbst ist weitgehend> vernachlässigbar, gerade für einzelne, große Dateien oder gar ganze> Festplatten.
Das ändert sich aber, wenn das Dateisystem anfängt, die letzten Bytes
zusammenzukratzen. Dann steigen sowohl Fragmentierung und CPU-Last bei
sinkender Performance ziemlich deutlich an.
S. R. schrieb:> Sheeva P. schrieb:>> Der Overhead durch das Dateisystem selbst ist weitgehend>> vernachlässigbar, gerade für einzelne, große Dateien oder gar ganze>> Festplatten.>> Das ändert sich aber, wenn das Dateisystem anfängt, die letzten Bytes> zusammenzukratzen. Dann steigen sowohl Fragmentierung und CPU-Last bei> sinkender Performance ziemlich deutlich an.
Wie gesagt: unter ungünstigen Umständen kann es auch bei
Linux-Dateisystemen zu einer Fragmentierung kommen. Aber wenn das
passiert, ist (vor allem auch angesichts aktueller Preise für
Festplatten) IMHO schon deutlich früher was schiefgelaufen -- erst bei
der Dimensionierung und dann beim Monitoring.
Thread beobachten
Seitenaufteilung abschalten