USB-Stick sicher löschen - wie? (2017)

Hast Du Probleme mit Hardware, die durch die anderen Foren nicht abgedeckt werden? Schau auch in den "Tipps und Tricks"-Bereich.
wanne
Moderator
Beiträge: 5548
Registriert: 24.05.2010 12:39:42

Re: USB-Stick sicher löschen - wie? (2017)

Beitrag von wanne » 06.11.2017 20:45:20

carlchen hat geschrieben: ↑ zum Beitrag ↑
06.11.2017 18:23:00
Wie auch debianoli schon schrieb, das wird nicht untergehen. Vielen Dank für den Tipp. :THX: Also ist cat zu empfehlen, damit die Haltbarkeit länger gewährleistet ist?
Kurz: Ja.
Länger: cat versucht die Größe der zu schreibenden Blöcke intelligent zu ermitteln das ist meist deutlich schonender als die 512Byte von dd. Du kannst auch mit dd über den bs= Parameter die Blockgröße festlegen. Wenn du die für den Stick passend festlegt kannst du natürlich genausogut sein (oder kannst sogar besser sein, wenn du dich intelligenter als cat anstellst, weil du die Hardware besser als der cat kennst.) Aber die defaults von 512Byte von dd sind halt alles andere als gut für USB-Sticks.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
heisenberg
Beiträge: 1321
Registriert: 04.06.2015 01:17:27

Re: USB-Stick sicher löschen - wie? (2017)

Beitrag von heisenberg » 06.11.2017 21:53:06

wanne hat geschrieben: ↑ zum Beitrag ↑
06.11.2017 16:10:19
Auch wenn es wieder unter gehen wird:

Code: Alles auswählen

dd if=/dev/zero of=/dev/USB-Stick
Macht das gleiche wie

Code: Alles auswählen

cat /dev/zero > /dev/USB-Stick
Nur das letzteres schneller geht.
Der Grund: Bei erstem Befehl wird mit den 2. 512 Byte erst angefangen, wenn die ersten fertig geschrieben sind.
Das ist in zweifacher Hinsicht unsinnig:
  • Die nächsten 512Byte könnten locker gelesen werden während noch die ersten geschrieben werden. Es gibt also immer eine Pause fürs Lesen, während geschrieben wird.
Ist das nicht nur so wenn man oflag=sync angibt?

Aber wie Du schon schriebst: Hier vollkommen vernachlässigbar. Falls man einen Cache braucht, dann wäre Debianmbuffer hilfreich.
Zuletzt geändert von heisenberg am 06.11.2017 22:12:22, insgesamt 3-mal geändert.

Benutzeravatar
heisenberg
Beiträge: 1321
Registriert: 04.06.2015 01:17:27

Re: USB-Stick sicher löschen - wie? (2017)

Beitrag von heisenberg » 06.11.2017 21:56:49

MSfree hat geschrieben: ↑ zum Beitrag ↑
06.11.2017 11:17:26
Eine zu große bs könnte dazu führen, daß das letzte Ende des Datenspeichers gar nicht bescrieben wird, wenn die Kapazität nicht exakt durch bs teilbar ist.
Ich habe die Ausgabe von dd bisher immer so interpretiert, das entweder ganze oder unvollständige Blöcke geschrieben werden, aber geschrieben wurde da immer.

wanne
Moderator
Beiträge: 5548
Registriert: 24.05.2010 12:39:42

Re: USB-Stick sicher löschen - wie? (2017)

Beitrag von wanne » 07.11.2017 00:13:59

heisenberg hat geschrieben: ↑ zum Beitrag ↑
06.11.2017 21:53:06
Aber wie Du schon schriebst: Hier vollkommen vernachlässigbar.
Ich würde das so nicht sagen. Auch kleine Unterbrechungen in schreiben führen ganz gerne mal zu größeren Wartezeiten.
Der Extremfall sind da CDs wenn denen mal das schreiben unterbrochen wurde, brauchen sie mehrere Sekunden, bis sie wieder weiterschreiben können. Aber auch Flash speicher haben durchaus ansprechzeiten, die deutlich länger als ein ununterbrochenes Schreiben sind.
Du kannst einfach mal benchmarken: Das wurde auch schon hier im Forum gemacht. cat ist merkbar schneller.
Ist das nicht nur so wenn man oflag=sync angibt?
I/O auf unformatierte devices ist immer synchron.
heisenberg hat geschrieben: ↑ zum Beitrag ↑
06.11.2017 21:53:06
Falls man einen Cache braucht, dann wäre Debianmbuffer hilfreich.
Die Paar Byte die die cat buffert sind mehr als ausreichend. Daneben hat eine einfache Pipe mittlerweile 65536Byte. für I/O in richtung Platte auch ohne zusätzliches mbuffer mehr als Ausreichend. Da brauchst du kein mbuffer mehr dazwischen.
Aber prinzipiell genau die Idee hinter mbuffer genau die. Wenn du schnellere und unregelmäßigere I/O hast, brauchst du größere Buffer und dann ist mbuffer das richtige Tool für dich.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
heisenberg
Beiträge: 1321
Registriert: 04.06.2015 01:17:27

Re: USB-Stick sicher löschen - wie? (2017)

Beitrag von heisenberg » 07.11.2017 09:19:17

Hmm... selbst wenn ich das auf die Spitze treibe und mal zum Testen nur Byteweise beschreibe um damit die Zugriffszahlen zu maximieren, kann ich da nur einen kaum bemerkbaren Unterschied sehen:

Code: Alles auswählen

root@desk:/media/usbstick# for((i=1;$i<=20;i++));do { dd </dev/zero bs=1c count=$((1024*1024*50)) >testfile ; } 2>&1 | grep -v Datens ; done
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,392 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,3795 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,5895 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,3803 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,5129 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,3975 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,794 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,4439 s, 2,0 MB/s
...
root@desk:/media/usbstick# for((i=1;$i<=20;i++));do { dd </dev/zero bs=1c count=$((1024*1024*50)) iflag=sync oflag=sync >testfile ; } 2>&1 | grep -v Datens ;done
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,4446 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,7176 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 27,181 s, 1,9 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 27,3521 s, 1,9 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 27,2663 s, 1,9 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 27,1722 s, 1,9 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,5311 s, 2,0 MB/s
...
Nachtrag: hier auch nochmal der Schreibvorgang mit Ausgabe direkt auf das Gerät(statt in ein Dateisystem):

Code: Alles auswählen

for((i=1;$i<=20;i++));do { dd </dev/zero bs=1c count=$((1024*1024*50))  >/dev/sdb ; } 2>&1 | grep -v Datens ;done
52428800 Bytes (52 MB, 50 MiB) kopiert, 23,8363 s, 2,2 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 23,4236 s, 2,2 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 23,4284 s, 2,2 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 23,1841 s, 2,3 MB/s
...
Ich habe einen normalen USB-Stick(USB 2) an einem schnellen Rechner verwendet.

Wenn also bei 50.000.000 Schreibzugriffen so wenig Auswirkung ist, würde ich sagen, dass die Ansprechzeiten des USB-Sticks hier vernachlässigbar sind.

Hier nochmal der Test, wenn ich mit etwas mehr Daten mit grösseren Blockgrössen(Standardblockgrösse = 512 Bytes) schreibe:

Code: Alles auswählen

for((i=1;$i<=20;i++));do { dd </dev/zero count=$((1024*1024))  >/dev/sdb ; } 2>&1 | grep -v Datens ;done                  
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,640451 s, 838 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,542197 s, 990 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,546151 s, 983 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,601548 s, 892 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,552735 s, 971 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,551296 s, 974 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,551773 s, 973 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,561011 s, 957 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,570087 s, 942 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 1,13311 s, 474 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,61497 s, 873 MB/s
Der popelige USB-Stick schafft diese Geschwindigkeit nie im Leben. D. h. ich vermute da wird überhaupt nix synchron geschrieben, sondern alles gecached , erst im Hintergrund auf den Stick geschrieben und die langsame Geschwindigkeit oben kommt nur daher, dass das System jedes Byte einzeln hin- und herschubsen muss.

Wenn ich auch mal verschiedene Bereiche beschreibe, dann sieht man da nochmal eine Veränderung:

Code: Alles auswählen

root@desk:/media/usbstick# for((i=1;$i<=100;i++));do { dd </dev/zero count=$((1024*100)) seek=$(($i*1024*100)) >/dev/sdb ; } 2>&1 | grep -v Datens ;done
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0885792 s, 592 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,126787 s, 414 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0974019 s, 538 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,101278 s, 518 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,102126 s, 513 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,129887 s, 404 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0890491 s, 589 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,102819 s, 510 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,101822 s, 515 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,128684 s, 407 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0905995 s, 579 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0901749 s, 581 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,128309 s, 409 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0901506 s, 582 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 20,2728 s, 2,6 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,097679 s, 537 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 119,756 s, 438 kB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0833935 s, 629 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 107,291 s, 489 kB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,124952 s, 420 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 112,425 s, 466 kB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0750392 s, 699 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 64,9629 s, 807 kB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0630086 s, 832 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 27,5559 s, 1,9 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0992653 s, 528 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 57,5047 s, 912 kB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,102086 s, 514 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 45,8611 s, 1,1 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0579088 s, 905 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 43,4918 s, 1,2 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,127354 s, 412 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 40,1855 s, 1,3 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 1,00295 s, 52,3 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 56,5088 s, 928 kB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 49,1058 s, 1,1 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 43,8796 s, 1,2 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 48,5203 s, 1,1 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 45,0704 s, 1,2 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 35,149 s, 1,5 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 44,1591 s, 1,2 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 51,5053 s, 1,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 43,5743 s, 1,2 MB/s
D. h. ich beschreibe bei jeder Iteration einen anderen Bereich. Sobald der Cache voll ist, müssen die Daten geschrieben werden, und dann geht die Schreibgeschwindigkeit auf die tatsächliche Geschwindigkeit runter, die der Stick leisten kann und wird dann erst wieder schnell, wenn die Daten aus dem Cache weggeschrieben sind. Wenn ich kontinuierlich schreibe, dann geht die Geschwindigkeit tendenziell in den Keller, wie oben zu sehen.

Lange Rede, kurzer Sinn

Ich sehe da nicht dass bei meinem System(Debian Stretch, Desktop-PC), beim direkten Schreiben auf eine USB-Stick-Gerätedatei, da irgendetwas synchron geschrieben wird.

Das hier scheint es zu erklären.
https://lwn.net/Articles/572911/

Bei mir steht dirty_ratio auf 10 (%). D. h. bei 16 GB RAM wird 1,6 GB für das Caching verwendet.

ren22
Beiträge: 412
Registriert: 26.11.2006 09:05:14

Re: USB-Stick sicher löschen - wie? (2017)

Beitrag von ren22 » 15.11.2017 18:18:27

ich geb auch mal mein Senf dazu,

also im Thread Kopf steht "sicher löschen" , dass bedeutet das jeder sektor mindestens 7x mit zufälligen Werten beschrieben werden muss! Besser sogar 35x jeden Sektor mit Zufallwerten beschreiben und das sehe ich "shred" schonmal als sehr brauchbar an:

ungetested:
shred --interation=35 --random-source=/dev/urandom --zero /dev/DEVICE

Radfahrer
Beiträge: 3501
Registriert: 15.12.2012 20:48:16
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Zu Hause

Re: USB-Stick sicher löschen - wie? (2017)

Beitrag von Radfahrer » 15.11.2017 18:39:49

Völliger Blödsinn.
"Glauben bedeutet, Behauptungen sogar gegen besseres (Nicht-)Wissen für wahr zu halten, ohne einen seriösen Beweis dafür zu verlangen. Und ohne zu hinterfragen, wie plausibel die Glaubensinhalte eigentlich wirklich sind."
https://wenigerglauben.de/

MSfree
Beiträge: 3478
Registriert: 25.09.2007 19:59:30

Re: USB-Stick sicher löschen - wie? (2017)

Beitrag von MSfree » 15.11.2017 19:25:30

ren22 hat geschrieben: ↑ zum Beitrag ↑
15.11.2017 18:18:27
also im Thread Kopf steht "sicher löschen" , dass bedeutet das jeder sektor mindestens 7x mit zufälligen Werten beschrieben werden muss! Besser sogar 35x
Das ist schon bei Festplatten Unsinn und für Flashspeicher schlicht und ergreifend komplett falsch. Nach einmaligem Überschreiben ist bei Flashspeicher keine Restinformation mehr aus dem "Hintergrundrauschen" zu bekommen.

Benutzeravatar
heisenberg
Beiträge: 1321
Registriert: 04.06.2015 01:17:27

Re: USB-Stick sicher löschen - wie? (2017)

Beitrag von heisenberg » 15.11.2017 19:43:20

MSfree hat geschrieben: ↑ zum Beitrag ↑
15.11.2017 19:25:30
ren22 hat geschrieben: ↑ zum Beitrag ↑
15.11.2017 18:18:27
also im Thread Kopf steht "sicher löschen" , dass bedeutet das jeder sektor mindestens 7x mit zufälligen Werten beschrieben werden muss! Besser sogar 35x
Das war mal ne Zeit lang in der Diskussion. Aber irgendwann hat man festgestellt, dass man 1 maligem Überschreiben vielleicht noch hier und da mal 1 BIT restaurieren könnte, aber von einer Datenmenge, aus der man tatsächlich brauchbare Informationen gewinnen könnte, war das dann doch extrem weit weg. Und damit hat sich der Satz: "Mindestens 20 Mal überschreiben" erledigt. Seitdem ist der Default bei shred auch wieder 3 Iterationen und das reicht Dicke.

Im übrigen freuen sich alle Computerhändler und Chiphersteller und können die Anzahl der Überschreibzyklen für sicheres löschen gar nicht hoch genug ansetzen. :)

Antworten