[gelöst] 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.
Antworten
Benutzeravatar
Houbey
Beiträge: 727
Registriert: 03.03.2012 05:13:32

[gelöst] USB-Stick sicher löschen - wie? (2017)

Beitrag von Houbey » 05.11.2017 15:27:10

Hallo Debianer, :hail:

ich würde gerne einen USB-Stick verschenken, doch dieser hatte schon viele Dateien von mir drauf. Davon waren es auch persönliche Daten. Ich habe einen Beitrag von 2008 hier gefunden und habe dementsprechend auch die Beitrags-Überschrift angepasst, da dies wohl eher als "wiederbeleben" angesehen werden kann.

In dem Beitrag wurde damals geschrieben, das es reichen würde, mit dd den USB-Stick zu nullen, allerdings ist ein USB-Stick doch ein Flashspeicher, wie eine SSD das auch ist, oder? Genügt es daher wirklich den USB-Stick zu nullen oder gibt es eine andere Methode? Das Secure Erase Verfahren, was man auch mittels hdparm anwenden kann, funktioniert auf einem USB-Stick nicht, zumindest bei mir nicht.

Vielleicht hat ja jemand von euch noch eine Idee oder Tipp? Vielen Dank schon einmal. :THX:
Zuletzt geändert von Houbey am 11.03.2020 12:51:47, insgesamt 2-mal geändert.
Viele Grüße
Houbey

------------------------------
Debian GNU/Linux 11.8 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit. 8)

Benutzeravatar
smutbert
Moderator
Beiträge: 8317
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

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

Beitrag von smutbert » 05.11.2017 15:48:49

ich glaube, dass es USB-Sticks gibt, die über mehr Speicherplatz verfügen als zugänglich ist. Dieser überschüssige Speicher wird dann als Reservespeicher verwendet um defekte Flashzellen zu ersetzen und für Wear-Leveling.
Dann würde am wie bei SSDs mit dem Überschreiben des kompletten Datenträgers sicher sein können, dass der überwiegender Teil der Daten unwiderbringlich futsch ist, aber man kann sich keinesfalls sicher sein, dass tatsächlich alle Daten unwiderbringlich verloren sind. Im Unterschied zur SSD gibt es aber kein Secure Erase oder etwas vergleichbares.
Ich habe auch schon die Empfehlung gelesen einen (geheimen) Schlüssel (zum Beispiel zur Verschlüsselung mittels luks) nicht unbedingt auf einen USB-Stick zu schreiben und zwar aus genau dem Grund, dass es schwer bis unmöglich ist, sicherzustellen, dass kein Fragment des Schlüssels mehr irgendwo auf dem Stick liegt.

Andererseits kann ich mich auch gut erinnern, dass mir schon jemand hier im Forum widersprochen und gemeint hat, USB-Sticks würden keinesfalls über Wear-Leveling verfügen (ob derjenige damit auch Reservespeicher für kaputte Speicherbereiche ausgeschlossen hat, die ja im wesentlich dasselbe Risiko bergen, weiß ich allerdings nicht mehr).

Ich meine für den Alltagsgebrauch ist das Überschreiben mit Nullen vollkommen ausreichend und mehr kann man bei USB-Sticks ohnehin nicht machen.

KP97
Beiträge: 3403
Registriert: 01.02.2013 15:07:36

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

Beitrag von KP97 » 05.11.2017 15:49:29

Alles als root ausführen:

Code: Alles auswählen

dd if=/dev/zero of=/dev/sdx(x) count=1
oder

Code: Alles auswählen

shred -n 1 -v /dev/sdx(x)
Das x mit dem Device ersetzen, die Klammern beziehen sich auf Partitionen, wenn es der ganze Stick ist, entfällt das.
Du kannst auch den Stick neu formatieren mit neuer Partitiontabelle, dann wird auch alles gelöscht.

Benutzeravatar
Houbey
Beiträge: 727
Registriert: 03.03.2012 05:13:32

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

Beitrag von Houbey » 05.11.2017 16:10:10

Hallo ihr zwei,

vielen Dank für eure Antworten. :THX:

Das formatieren soll ja normalerweise die Dateien physisch nicht wirklich löschen, sondern lediglich als freien Speicher markieren. Betrifft das auch USB Sticks dann oder lediglich magnetische Festplatten, also HDDs? Denn da kann man ja ohne Probleme mittels dd, DBAN, cat etc. die gesamte Platte vollschreiben lassen.

@ KP97, was bedeutet denn das count=1 ?

@ smutbert, ich habe zwar des öfteren die USB-Sticks mit nullen überschrieben, war mir allerdings nicht mehr so sicher, als ich einen Beitrag gelesen habe, das USB-Sticks lediglich die "langsameren" SSDs vergleichsweise sein sollen. Daher auch meine Frage zwecks Flash-Speichers. :THX:
Zuletzt geändert von Houbey am 11.03.2020 12:52:07, insgesamt 1-mal geändert.
Viele Grüße
Houbey

------------------------------
Debian GNU/Linux 11.8 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit. 8)

KP97
Beiträge: 3403
Registriert: 01.02.2013 15:07:36

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

Beitrag von KP97 » 05.11.2017 17:17:45

Count=1 bedeutet erster Startsektor
Das kann man aber auch weglassen oder hier mal nachlesen:
https://wiki.ubuntuusers.de/dd/

Zu SSD's kann ich mangels Vorhandensein nichts sagen, da weiß @smutbert sicher mehr.

Benutzeravatar
ralli
Beiträge: 3900
Registriert: 02.03.2008 08:03:02

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

Beitrag von ralli » 05.11.2017 20:06:53

Zu SSD komplett löschen kann ich etwas beitragen.
Ich mache es immer als root aus der Konsole, meist mit einer Knoppix Live DVD. Sollte aber auch ohne Knoppix funktionieren.

blkdiscard -v /dev/sdx

partprobe /dev/sdx

neu booten

Das x muß natürlich ersetzt werden je nach device evt. sda, sdb usw. Das geht aber nicht mit USB Sticks!

Es ist immens schnell ....
Wer nicht lieben kann, muß hassen. Wer nicht aufbauen kann muß zerstören.

pferdefreund
Beiträge: 3791
Registriert: 26.02.2009 14:35:56

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

Beitrag von pferdefreund » 06.11.2017 08:36:11

Wenn es um absolute Sicherheit geht, hilft nur thermisches Vernichten - ist zwar nicht ganz umweltfreundlich, aber wirklich sicher.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

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

Beitrag von MSfree » 06.11.2017 08:49:10

pferdefreund hat geschrieben: ↑ zum Beitrag ↑
06.11.2017 08:36:11
Wenn es um absolute Sicherheit geht, hilft nur thermisches Vernichten
Mechanisches Vernichten reicht auch. Wenn du die Chips mit einem Hammer zertrümmerst, kommst du auch nichtmehr an die Daten ran. :wink:

Bei USB-Sticks reicht aber das Beschreiben mit Nullen völlig aus. Da ist auch nach dem Nullen keine "Restinformation" mehr vorhanden. Vor allem die billigen USB-Sticks (gefühlsmässig alles bis 64GB) haben garantiert keine Reservezellen. Auch über Wearlevelling verfügen sie in der Regel nicht. Wobei Wearlevelling auch ohne Reservezellen realisierbar ist, und nichts mit der Löschfähigkeit zu tun hat.

debianoli
Beiträge: 4068
Registriert: 07.11.2007 13:58:49
Wohnort: Augschburg

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

Beitrag von debianoli » 06.11.2017 09:41:13

KP97 hat geschrieben: ↑ zum Beitrag ↑
05.11.2017 15:49:29
Alles als root ausführen:

Code: Alles auswählen

dd if=/dev/zero of=/dev/sdx(x) count=1
Da gehört doch noch die Byte-Size dazu? Oder kann man das da weglassen?

Code: Alles auswählen

dd if=/dev/zero of=/dev/Usbstick bs=1024

Benutzeravatar
Houbey
Beiträge: 727
Registriert: 03.03.2012 05:13:32

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

Beitrag von Houbey » 06.11.2017 10:50:41

Vielen Dank für eure ganzen Antworten. Das hilft mir schon sehr viel. :THX:

@ debianoli, die bs kannst du auch weglassen, da dd standardmäßig immer mit 512 bytes überschreibt. Außer du möchtest es beschleunigen, dann ist das so wie du geschrieben hast, eigentlich korrekt.

Wäre der Befehl dann mit dem count wie folgt?:

Code: Alles auswählen

dd if=/dev/zero of=/dev/USB-Stick bs=1M count=1
oder muss das bs wenn man es eintragen möchte, ans Ende, hinter dem count?
Zuletzt geändert von Houbey am 11.03.2020 12:52:47, insgesamt 1-mal geändert.
Viele Grüße
Houbey

------------------------------
Debian GNU/Linux 11.8 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit. 8)

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

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

Beitrag von MSfree » 06.11.2017 11:17:26

carlchen hat geschrieben: ↑ zum Beitrag ↑
06.11.2017 10:50:41
Wäre der Befehl dann mit dem count wie folgt?:

Code: Alles auswählen

dd if=/dev/zero of=/dev/USB-Stick bs=1M count=1
Nein, bs=1M count=1 überschreibt nur das erste Megabyte des Sticks.

Um wirklich sicher zu gehen, muß man count und bs weglassen.
count gibt nämlich an, wie oft der mit bs angegeben Block geschrieben werden soll.

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.

KP97
Beiträge: 3403
Registriert: 01.02.2013 15:07:36

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

Beitrag von KP97 » 06.11.2017 15:10:37

MSfree hat geschrieben: ↑ zum Beitrag ↑
06.11.2017 08:49:10
Wenn du die Chips mit einem Hammer zertrümmerst, kommst du auch nichtmehr an die Daten ran. :wink:
Na, da wird der Beschenkte aber Augen machen...;-)
@MSfree
Danke für den Hinweis zu count, war mir so nicht bekannt.

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

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

Beitrag von wanne » 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.
    Da /dev/zero extrem schnell ist, ist das in dem Beispiel eher harmlos. Beim Kopieren eines Sticks auf den anderen ist da gerne mal der Faktor 2 drin. (Wenn lesen und schreiben gleich schnell ist, wird die Hälfte der Zeit gelesen und die Hälfte geschrieben. Statt die ganze Zeit gleichzeitig zu lesen und zu schreiben.)
  • USB-Sticks können oft nur 4096-Blöcke schreiben. – Bei der dd-variante werden also die ersten 4096Byte gelesen, die ersten 512byte ausgetauscht und wieder geschrieben. Danach erneut gelesen, die 2. 512Byte ausgetauscht und erneut geschrieben...
    Am Ende hat man den gleichen ersten Block 8 statt ein mal geschrieben. Das ist nicht nur langsam sondern auch nicht sonderlich gut für die Haltbarkeit des Sticks.
    Die meisten Sticks fangen das mit Caches ab. Trotzdem bleibt da immer ein ziemlich signifikanter Unterschied.
rot: Moderator wanne spricht, default: User wanne spricht.

debianoli
Beiträge: 4068
Registriert: 07.11.2007 13:58:49
Wohnort: Augschburg

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

Beitrag von debianoli » 06.11.2017 17:11:51

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.
Nein, das geht nicht unter. Danke für den Tipp.

Benutzeravatar
Houbey
Beiträge: 727
Registriert: 03.03.2012 05:13:32

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

Beitrag von Houbey » 06.11.2017 18:23:00

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.
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?
Zuletzt geändert von Houbey am 11.03.2020 12:53:11, insgesamt 1-mal geändert.
Viele Grüße
Houbey

------------------------------
Debian GNU/Linux 11.8 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit. 8)

wanne
Moderator
Beiträge: 7448
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: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

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.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

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.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

wanne
Moderator
Beiträge: 7448
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: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

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.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

ren22

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

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

Beitrag von Radfahrer » 15.11.2017 18:39:49

Völliger Blödsinn.

Benutzeravatar
MSfree
Beiträge: 10686
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: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

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. :)
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
Houbey
Beiträge: 727
Registriert: 03.03.2012 05:13:32

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

Beitrag von Houbey » 19.11.2018 20:14:12

Die Diskussiom um die Statusanzeige von cat wurde nach Status für cat verschoben
Das hat den Beitrag um die Bitte danach etwas aus dem Kontext genommen. --wanne
Ursprünglicher Beitrag:
carlchen hat geschrieben:Alles klar, das kann ich machen. Werde mich gleich mal mit einem Mod in Verbindung setzen.
Dankeschön für eure Antworten. :THX:
Viele Grüße
Houbey

------------------------------
Debian GNU/Linux 11.8 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit. 8)

Antworten