Hallo zusammen, ist es eigentlich normal, dass Secure Erase bei einer SSD nur wenige Sekunden dauert? Habe hier eine Samsung 840 EVO mit 120 GB in gefühlt 10 Sekunden gelöscht, möglicherweise waren es nicht mal 10 Sekunden. Was genau passiert da intern in den wenigen Sekunden? Viele Grüße Paul
Ach ja, habe mit Samsung Magician gelöscht, die SSD war ganz normal über SATA angeschlossen.
Ich würde mal annehmen, dass es eine Steuerleitung für 'Inhalt löschen' gibt oder sich alle Speicherzellen auf einmal adressieren lassen. Dann geht das löschen oder überschreiben ziemlich schnell. Das ist jetzt nur eine Vermutung.
Ich habe keine Werte zu aktuellen Flash-Chips im Kopf, aber vor Jahren lag die Grösse eines Erase-Blocks bereits bei 0,5 MB. Wenn ein Löschvorgang 2 Millisekunden benötigt, dann liegt man rein sequentiell bei 4 Sekunden pro GB. Die Blöcke werden mittlerweile wohl entsprechend grösser geworden sein, und die einzelnen Chips einer SSD können parallel gelöscht werden.
Bernd K. schrieb: > Oder sie löscht einfach den Schlüssel und generiert einen neuen. Genau so ist es.
Vermutlich wurde gar nichts gelöscht. Eventuell verschlüsselt die SSD standardmäßig alle Sektoren und hat auf den Befehl zum "Secure Erase" hin gar nichts physisch gelöscht, sondern nur den Schlüssel vernichtet. Damit kann man die Platte den Inhalt nicht mehr entschlüsseln. Um zu beurteilen, ob ein stattlicher staatlicher Angreifer das vielleicht doch kann, müsste man die Firmware der Platte disassemblieren oder besser noch gleich den Quellcode durchlesen. Du könntest mit einem Hexeditor versuchen, die Platte auszulesen. Ist alles auf Null? Ich bevorzuge sequentielles Löschen per Software. Allerdings können die ATA-Eigenschaften wie "Secure Erase" eventuell noch mehr löschen, nämlich Sektoren, die man von Außen mit Bordmitteln nicht auslesen kann.
Peter M. schrieb: > Um zu beurteilen, ob ein stattlicher staatlicher Angreifer das > vielleicht doch kann, Daten die ernsthaft vor staatlichem Zugriff geschützt werden sollen weil das persönliche Wohlergehen oder das Anderer davon abhängt verschlüsselt man lieber selbst und zwar mit einer Software der man vertraut. Alles andere ist Spielzeug.
Bissel im Web gegraben: Es scheint keine einheitliche Linie zu geben. - Manche löschen auch den Inhalt, obwohl verschlüsselt wird. Allein schon, weil gelöschte Blöcke sofort überschrieben werden können, somit die Performance anschliessend wieder maximal ist. - Manche ersetzen bloss den Schlüssel. Geht schneller, aber die Blöcke können dann noch nicht sofort überschrieben werden. Letztlich verlagert es die Löscherei auf später. - Es soll auch welche geben, oder gegeben haben, bei denen das ganze Verfahren Augenwischerei ist und man hinterher trotzdem noch rankommt.
Hallo, danke für die Antworten. Die SSD ist von einem Bekannten und ich habe die für mich bekommen, allerdings mit der Auflage, seine Daten zu löschen. Es geht also nicht darum, forensischen Untersuchungen zu trotzen. Das mit dem Schlüssel hatte ich auch überlegt, allerdings habe ich häufig in Foren gelesen, dass ein SecureErase nach längerem Betrieb ohne TRIM auch eine Art "Frischzellenkur" darstellen kann(sofern die Zellen nicht schon total runtergerockt ist), nach der die Schreibrate dann wieder wie ab Werk ist. Schade, dass es da keine einheitliche Linie zu geben scheint.
Bernd K. schrieb: > Daten die ernsthaft vor staatlichem Zugriff geschützt werden sollen weil > das persönliche Wohlergehen oder das Anderer davon abhängt verschlüsselt > man lieber selbst und zwar mit einer Software der man vertraut. Alles > andere ist Spielzeug. Ja, sehe ich genauso. A. K. schrieb: > - Es soll auch welche geben, oder gegeben haben, bei denen das ganze > Verfahren Augenwischerei ist und man hinterher trotzdem noch rankommt. Ja. Es gibt keinen Grund den Festplattenherstellern zu vertrauen.
Paul schrieb: > allerdings mit der Auflage, seine Daten zu löschen. Es geht also nicht > darum, forensischen Untersuchungen zu trotzen. In diesem Fall wird das Secure Erase ausreichen.
Peter M. schrieb: > Bernd K. schrieb: >> Daten die ernsthaft vor staatlichem Zugriff geschützt werden sollen weil >> das persönliche Wohlergehen oder das Anderer davon abhängt verschlüsselt >> man lieber selbst und zwar mit einer Software der man vertraut. Alles >> andere ist Spielzeug. > > Ja, sehe ich genauso. > > A. K. schrieb: >> - Es soll auch welche geben, oder gegeben haben, bei denen das ganze >> Verfahren Augenwischerei ist und man hinterher trotzdem noch rankommt. > > Ja. Es gibt keinen Grund den Festplattenherstellern zu vertrauen. also ob man heute irgendwelcher Software vertrauen kann. Wenn schon Paranoid dann bitte richtig. Also nur eigene Software ist sicher. Linux oder was auch immer mit Millionen zeilen code kann niemand überblicken ob es 100% sicher ist. In jedem Update kann dir etwas eingespielt werden, was den key ins netzt verschickt ohne das du es merkst.
Peter II schrieb: > also ob man heute irgendwelcher Software vertrauen kann. Wenn schon > Paranoid dann bitte richtig. Bitte zieh' Deinen Aluhut aus, bevor Du mit mir sprichst, damit nicht Dein Hut mit meinem zusammenstösst! :) Über Deine Aussage bin ich enttäuscht. Quellcodeoffene Software ist die Lösung.
Peter II schrieb: > Also nur eigene Software ist sicher. Eines ist sicher: Eigene Verschlüsselungssoftware ist unsicher. Also wenn man nicht grad Bruce Schneier heisst, oder so.
Peter M. schrieb: > Quellcodeoffene Software ist die Lösung. ja, klar doch. Die Vergangenheit hat ja gezeigt, das Opensource 100% sicher ist.
Paul schrieb: > SecureErase nach längerem Betrieb ohne > TRIM auch eine Art "Frischzellenkur" darstellen kann Dagegen hilft doch das simple Einschalten von TRIM, evtl vielleicht einmal manuell TRIMen, kein Grund deswegen gleich die ganze Platte zu löschen.
Bernd K. schrieb: > kein Grund deswegen gleich die ganze Platte zu löschen. Genau das war aber die Vorgabe.
A. K. schrieb: >> kein Grund deswegen gleich die ganze Platte zu löschen. > > Genau das war aber die Vorgabe. aber nur weil es nicht genauer beschrieben wurde. Es sollten alle Daten unwiderruflich gelöscht werden. Dafür ist ein überschreiben bei einer SSD nicht geeignet, weil man damit die Reserve Sektoren nicht erwischt.
A. K. schrieb: > Eines ist sicher: Eigene Verschlüsselungssoftware ist unsicher. Ja! Ich habe auch mal für private Zwecke einen Algorithmus geschrieben und den habe ich für ziemlich ausgefuchst gehalten. Nach späterer Lektüre von Artikeln über Kryptologie kann ich über mich in diesem Punkt nur ganz herzhaft lachen. > Also wenn man nicht grad Bruce Schneier heisst, oder so. Nein! Auch akademische Reputation schützt vor Kryptopleiten nicht. Der Witz besteht in der gegenseitigen Prüfung der Machwerke, der auch z.B. anlässlich des AES-Wettbewerbs stattgefunden hat. Peter II schrieb: > Die Vergangenheit hat ja gezeigt, das Opensource 100% sicher ist. Bist Du staatlicher Schnüffler und möchtest gerne mit der Microsoft'schen FUD-Strategie das Konzept von "Open Source" torpedieren, oder bist Du nur ein Troll? Oder unterstellst Du anderen gerne Dinge, die sie nicht gesagt haben? Egal, hier im Forum kannst Du Deine perversen Neigungen nach besten Kräften ausleben.
Peter II schrieb: > aber nur weil es nicht genauer beschrieben wurde. Es sollten alle Daten > unwiderruflich gelöscht werden. Beachte die Präzisierung um 20:34. Nix unwiderruflich. > Dafür ist ein überschreiben bei einer SSD nicht geeignet, weil man damit > die Reserve Sektoren nicht erwischt. Ein Secure Erase in den von ihm genannten gefühlten 10 Sekunden passiert garantiert nicht per Überschreiben. Was nahelegt, dass das Samsung-Tool verwendet wurde.
Peter M. schrieb: >> Also wenn man nicht grad Bruce Schneier heisst, oder so. > > Auch akademische Reputation schützt vor Kryptopleiten nicht. Klar. Aber für Laien stehen die Chancen doch noch ein klein wenig schlechter. Und grad der Experte wird das schon realistisch einschätzen, der braucht meinen Tipp nicht. ;-)
:
Bearbeitet durch User
A. K. schrieb: > Klar. Aber für Laien stehen die Chancen doch noch ein klein wenig > schlechter. Auf jeden Fall.
Peter M. schrieb: > Ja! Ich habe auch mal für private Zwecke einen Algorithmus geschrieben > und den habe ich für ziemlich ausgefuchst gehalten. Jeder kann einen Verschlüsselungsalgorithmus entwerfen, den er mit seinem aktuellen Wissen nicht knacken kann ;)
A. K. schrieb: > Peter M. schrieb: >>> Also wenn man nicht grad Bruce Schneier heisst, oder so. >> >> Auch akademische Reputation schützt vor Kryptopleiten nicht. > > Klar. Aber für Laien stehen die Chancen doch noch ein /klein wenig/ > schlechter. Und grad der Experte wird das schon realistisch einschätzen, > der braucht meinen Tipp nicht. ;-) Da hatte Fefe noch was die Tage... Von wegen Experten: https://de.wikipedia.org/wiki/Magenta_(Algorithmus) Telekom Beitrag zum DES-Nachfolger: "Die Kryptologen Adi Shamir und Ross Anderson fanden bereits während der 20-minütigen Präsentation des Algorithmus theoretische Angriffsmöglichkeiten. Kurze Zeit später bewiesen sie, dass dieser Angriff auch praktisch möglich und das Kryptosystem somit leicht zu brechen ist."
Peter M. schrieb: > Bist Du staatlicher Schnüffler und möchtest gerne mit der > Microsoft'schen FUD-Strategie das Konzept von "Open Source" torpedieren, > oder bist Du nur ein Troll? > > Oder unterstellst Du anderen gerne Dinge, die sie nicht gesagt haben? Er ist ein bekannter MS-Troll. Das macht er schon seit Jahren. Arc N. schrieb: > Da hatte Fefe noch was die Tage... Von wegen Experten: https://blog.fefe.de/?ts=a6c1f1d3 Als hätte die Telekom irgendeine Ahnung von Sicherheit. Wie siehts mit sicherem Löschen eigentlich bei "defekten" Sektoren aus? Sowohl SSD als auch HDD haben da ja spezielle Bereiche. Bei SSD sind "verbrauchte" Sektoren aber normal noch (schwierig) lesbar, aber nur nicht mehr schreibbar.
T.roll schrieb: > Bei SSD sind > "verbrauchte" Sektoren aber normal noch (schwierig) lesbar, aber nur > nicht mehr schreibbar. Kaputte Flash-Zellen sind nicht mehr Beschreibbar, aber noch Löschar. Deshalb ist das SATA secure erase immer als erster Schritt sinnvoll, je nach Paranoia kann man ja noch ein full-device Trim und Überschreiben mit schlecht komprimierten Daten (mp3 oder Videosammlung ?) hinterher schieben.
Wenn man ein secure erase triggert, dann ist das DER Hinweis für die Firmware das ALLE flash-pages gelöscht werden können. Bei SSDs mit interner Verschlüsselung wird - wie schon gesagt - als erstes der interne Schlüssel verworfen. Damit sind die Daten für Anwender schon nicht mehr lesbar. Gleichzeitig wird die Firmware vormerken und beginnen den kompletten Flash zu trimmen. Einen besseren Zeitpunkt für interne Aufräumarbeiten kann und wird es nie geben. Man muss die SSD einfach nur eine gewisse Zeit an der Betriebsspannung bzw. eingeschaltet lassen.
Peter II schrieb: > ja, klar doch. > > Die Vergangenheit hat ja gezeigt, das Opensource 100% sicher ist. Sicherer als Windows allemal, siehe zB: https://de.wikipedia.org/wiki/Bruce_Schneier unter "Werke, letzter Absatz: Zitat: "Im November 2007 wies er im Technologie-Magazin Wired darauf hin, dass nach seiner Ansicht in einem der vier vom NIST im März 2007 veröffentlichten[1] kryptografischen Zufallszahlengeneratoren, nämlich dem Dual Elliptic Curve Deterministic Random Bit Generator (Dual EC DRBG), möglicherweise eine Backdoor eingebaut sei. Erwähnenswert ist, dass die Auswahl dieses Generators für die Standardisierung vor allem auf Drängen der NSA erfolgt sein soll.[2][3] Dieser Zufallszahlengenerator ist auch mit Service Pack 1 in Windows Vista enthalten.[4][5] Der Verdacht auf eine Backdoor wurde 2013 durch die von Edward Snowden enthüllten Dokumente bestätigt.[6]"
Paul schrieb: > Habe hier eine Samsung 840 EVO mit 120 GB in gefühlt 10 Sekunden > gelöscht, möglicherweise waren es nicht mal 10 Sekunden. Wenn man mal in das Datenblatt eines Flash-ICs schaut, z.B. H27UAG8T2BTR-BC, dann dauert ein Block-Erase typisch 2,5ms und er enthält 512 Blöcke. D.h. nach 1,3s ist der gesamte Flash gelöscht. Und natürlich kann der Controller die Erase-Befehle an alle Flash-ICs gleichzeitig senden.
Der Andere schrieb: > Dieser > Zufallszahlengenerator ist auch mit Service Pack 1 in Windows Vista > enthalten.[4][5] Der Verdacht auf eine Backdoor wurde 2013 durch die von > Edward Snowden enthüllten Dokumente bestätigt.[6]" Dummerweise haben nur wenige CPUs einen echten Zufallszahlengenerator. Mir fallen hier nur die veralteten CPUs von VIA ein. Bei allem anderem muss man sich mit mehr oder weniger (un)brauchbarer Software behelfen.
Schreiber schrieb: > Dummerweise haben nur wenige CPUs einen echten Zufallszahlengenerator. > Mir fallen hier nur die veralteten CPUs von VIA ein. Intel enthält ab Ivy Bridge einen RdRand Befehl, AMD zog nach: https://en.wikipedia.org/wiki/RdRand http://electronicdesign.com/learning-resources/understanding-intels-ivy-bridge-random-number-generator#1 http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator Davor war das bereits Teil des optionalen Trusted Platform Module (TPM). Inwieweit man solchen Verfahren trauen will, oder doch lieber dem eigenen Aluhut (*), ist eine andere Frage. Der sich der Wikipedia Artikel auch widmet. *: o tempora o mores. Galten früher Aluhüte als untrügliches Kennzeichen für Spinner, entwickeln sie sich zunehmend zum etablierten Element elektronischen Daseins.
:
Bearbeitet durch User
Schreib doch ein 128GB File drauf: dd if=/dev/random of=/dev/sdx bs=512M (x=Deine SSD) Alternativ unter Windows große Dateien erzeugen und duplizieren.
Pete K. schrieb: > Schreib doch ein 128GB File drauf: > dd if=/dev/random of=/dev/sdx bs=512M (x=Deine SSD) Hast du das mal ausprobiert? Die SSD ist eher zu Staub zerfallen als vollgeschrieben. /dev/random ist kein Performance-Wunder, da die Menge an Entropie begrenzt ist. Besonders in virtuellen Umgebungen, in denen es schon etliche Minuten dauert, einen 4Kbit-RSA-Key da rauszuzupfen. Wenn schon, dann /dev/urandom. Aber dieses Verfahren ist bei SSDs nicht wirklich sinnvoll, jedenfalls wenn man es ernst meint, da aufgrund der Technik von SSDs nicht gewährleistet ist, dass wirklich alle Daten überschrieben werden.
:
Bearbeitet durch User
A. K. schrieb: > Wenn schon, dann /dev/urandom. Noch schneller: # cryptsetup open /dev/sdx --type plain crypt_sdx Am Password-Promt: Einmal Kopf auf die Tastatur hauen. dann ionice -c3 dd if=/dev/zero of=/dev/mapper/crypt_sdx bs=1M Nicht ganz dasselbe wie /dev/(u)random, aber es ist wenigstens wieder die Platte das limitierende, nicht der RNG.
Planlos schrieb: > random Das random setzt voraus, daß wirklich Zufall im Spiel ist. Das hatte ich früher schon, als beim Befehl rnd das Refesh-Register Zufall "spielen" sollte. Zufälligerweise waren die Zeichenfolgen immer gleich am Anfang:-) Es gibt da noch viele Möglichkeiten scheinbare Sicherheit zu erzeugen. Manche dieser Maßnahmen machen die Leute erst besonders neugierig. Grabt mal ein tiefes Loch im Garten. Da fragt bestimmt einer ...
Es geht ja nur darum, die Platte mit neuen Werten zu beschreiben, damit die alten Daten auch wirklich überschrieben werden. Ob man da random oder null oder etwas anderes nimmt ist völlig egal. Wichtig ist nur, dass die Platte ausreichend vollgeschrieben wird. Dann sind auch sicher die alten Daten komplett gelöscht.
:
Bearbeitet durch User
Pete K. schrieb: > Wichtig ist nur, dass die Platte ausreichend vollgeschrieben wird. Dann > sind auch sicher die alten Daten komplett gelöscht. genau das ist bei einer SSD nicht der Fall. Reservesektoren kann man mit überschreiben nicht erreichen. Später werden sie von der Firmware eventuell wieder sichtbar gemacht und dann sind ein teil der Daten wieder da.
Peter II schrieb: > Pete K. schrieb: >> Wichtig ist nur, dass die Platte ausreichend vollgeschrieben wird. Dann >> sind auch sicher die alten Daten komplett gelöscht. > > genau das ist bei einer SSD nicht der Fall. > > Reservesektoren kann man mit überschreiben nicht erreichen. Später > werden sie von der Firmware eventuell wieder sichtbar gemacht und dann > sind ein teil der Daten wieder da. HDDs haben ebenfalls Reserve-Sektoren.
Peter II schrieb: > Reservesektoren kann man mit überschreiben nicht erreichen. Später > werden sie von der Firmware eventuell wieder sichtbar gemacht und dann > sind ein teil der Daten wieder da. "wieder sichtbar gemacht": Wie soll das bitte funktionieren? So ein Vorgang ist technisch gesehen sinnlos. Reservesektoren sind jungfräulich und mit Festplattenkauf unbeschrieben. Sie enthalten keine Benutzerdaten. Nach meinem Verständnis werden Sektoren, die nicht mehr beschreibbar sind, auf einen dieser Reservesektoren umgeroutet. Ab diesem Moment ist so ein Sektor für das Betriebssystem auch erreichbar. Bei einer Löschaktion durch Nullen oder Überschreiben mit irgendeinem Wert wird so ein "ersetzter" Sektor auch überschrieben. Es gibt also nur jungfräuliche versteckte Reservesektoren oder zugängliche in Benutzung. Ein Sektor der nicht mehr lesbar ist, ist eventuell noch mit einem Schreibvorgang wieder benutzbar. In diesem Fall wird kein Reservesektor in Anspruch genommen. Erst wenn der Schreibvorgang scheitert, muss der Sektor ersetzt werden. Interessant sind die nicht mehr beschreibbaren Defektsektoren und die hängenden Sektoren, also solche, die nicht mehr lesbar sind. Ob ein Labor solche hängenden oder ersetzten Defektsektoren wohl auslesen kann?
Peter M. schrieb: > Nach meinem Verständnis werden Sektoren, die nicht mehr beschreibbar > sind, auf einen dieser Reservesektoren umgeroutet. Für Flash ist das eine reichlich bescheuerte Idee. Denn damit ist die Mehrheit der Sektoren schon stark belastet, wenn sie durch jungfräuliche Sektoren ersetzt werden. Da die anderen Sektoren aber auch schon alt sind, reichen deine Reservesektoren nicht aus und du hast schnelle Totalausfälle bei gleichzeitig verschwendetem Flash. Wear-Levelling basiert auf der Idee, dass die Schreibzugriffe durch den gesamten Flash (inklusive der Reservesektoren) wandern. Damit altert jeder Sektor ungefähr gleich schnell.
S. R. schrieb: > Peter M. schrieb: >> Nach meinem Verständnis werden Sektoren, die nicht mehr beschreibbar >> sind, auf einen dieser Reservesektoren umgeroutet. > > Für Flash ist das eine reichlich bescheuerte Idee. Denn damit ist die > Mehrheit der Sektoren schon stark belastet, wenn sie durch jungfräuliche > Sektoren ersetzt werden. Da die anderen Sektoren aber auch schon alt > sind, reichen deine Reservesektoren nicht aus und du hast schnelle > Totalausfälle bei gleichzeitig verschwendetem Flash. > > Wear-Levelling basiert auf der Idee, dass die Schreibzugriffe durch den > gesamten Flash (inklusive der Reservesektoren) wandern. Damit altert > jeder Sektor ungefähr gleich schnell. Danke für den Hinweis, S.R., ich war mental bei herkömmlichen Platten. Inhaltlich kann ich Dir nicht widersprechen. Damit hat aber auch der von mir oben kritisierte Peter II wieder Recht! Dank Wear-Levelling können noch funktionierende Sektoren dem Betriebssytem entzogen werden und der Zugriff auf ein Datenduplikat umgeroutet werden.
Pete K. schrieb: > Es geht ja nur darum, die Platte mit neuen Werten zu beschreiben, damit > die alten Daten auch wirklich überschrieben werden. > Ob man da random oder null oder etwas anderes nimmt ist völlig egal. Nein. Flash-Controler komprimieren gerne. Beim Überschreiben mit 0 freut der sich, 2% der Flash-Zellen sind nachher überschrieben, der Rest unangetastet. Bei random, Videofiles, verschlüsselten Daten kann er nicht komprimieren, d.h. nachher ist wirklich alles, bis auf die Reservesektoren, überschrieben. Also ein viel besserer Paranoia-Aluhut, wenn man dem Secure-Erase nicht vertraut. Auch wenn's wieder nicht 100%ig ist, doppelt hält besser, wie Gummi und Pille...
Planlos schrieb: > ionice -c3 dd if=/dev/zero of=/dev/mapper/crypt_sdx bs=1M Das ionice bringt aber nur mit dem richtigen IO-Scheduler was. Mit dem standardmäßig bei z.B. Debian oder Ubuntu eingestellten deadline scheduler nutzt das genau: nix. Also erst umstellen auf den cfq scheduler: echo "cfq" > /sys/block/sdx/queue/scheduler
Peter II schrieb: > Reservesektoren kann man mit überschreiben nicht erreichen. Später > werden sie von der Firmware eventuell wieder sichtbar gemacht und dann > sind ein teil der Daten wieder da. Ach, und diese Reservesektoren binden sich auch gleich ins Dateisystem ein und zeigen einem die alten Dateien? Das möchte ich sehen. Ich halte das Risiko der von mir beschriebenen Methode im privaten Umfeld für ausreichend. Zitat des TO: "Es geht also nicht darum, forensischen Untersuchungen zu trotzen."
:
Bearbeitet durch User
Pete K. schrieb: > Zitat des TO: "Es geht also nicht darum, forensischen Untersuchungen zu > trotzen." Und genau deswegen ist die ganze Diskussion in Bezug auf das OP so sinnlos. Die 840er Evo macht intern 256 Bit AES, das Verwerfen des Schlüssels, also das, was die Samsung-Software macht, reicht auch für mehr als Hausgebrauch völlig aus. Das ganze Palaver um Reservesektoren ist in diesem Kontext ebenfalls sinnlos - auch diese unterliegen der Verschlüsselung. Wer meint, er könnte in überschaubarer Zeit unter Zuhilfenahme eines gut ausgerüsteten Labors Inhalte aus 256 Bit AES-Verschlüsselten Flashchips wieder herstellen: Bitte melden. Ich opfere dafür eine SSD!
Pete K. schrieb: > Ich halte das Risiko der von mir beschriebenen Methode im privaten > Umfeld für ausreichend. ist es auch, aber des "Secure Erase" ist es genauso und dabei schonender für die SSD und auch schneller.
Planlos schrieb: > Nein. Flash-Controler komprimieren gerne. Tun sie das wirklich? Ich glaube nicht. Bei meiner SSD merke ich keinen Performance-Unterschied zwischen Nullbytes und Datenbytes, und zumindest bei SD-Karten laufen die Daten am Flash-Controller vorbei, nicht hindurch. Letzterer kümmert sich um die Verwaltung, nicht um Kompression. Außerdem ist "Nullbytes schreiben" eine äußerst seltene Anwendung, da wird nicht drauf optimiert (im Gegensatz zu bestimmten Dateisystemen).
S. R. schrieb: > Planlos schrieb: >> Nein. Flash-Controler komprimieren gerne. > > Tun sie das wirklich? Ich glaube nicht. doch machen sie, zumindest bei einige Herstellern. Samsung mit ihren eigenen Kontroller hat es aber noch nie gemacht.
S. R. schrieb: > Planlos schrieb: >> Nein. Flash-Controler komprimieren gerne. > > Tun sie das wirklich? Ich glaube nicht. Dieser Sandforce-Müll macht das. Deswegen kauft man all das besser nicht: http://geizhals.de/?cat=hdssd&xf=6964_SandForce Die einzigen, die einen Sandforce-Controller dank eigener Firmware einigermaßen im Griff hatten, waren Plextor und Intel.
Onkel Hotte schrieb: > Dieser Sandforce-Müll macht das. Ich hätte gedacht, dass niemand so bescheuert wäre, aber nun gut...
Onkel Hotte schrieb: > S. R. schrieb: >> Planlos schrieb: >>> Nein. Flash-Controler komprimieren gerne. >> >> Tun sie das wirklich? Ich glaube nicht. > > Dieser Sandforce-Müll macht das. Wie soll das denn eigentlich überhaupt sinnvoll gehen? Nehmen wir an ich hab ne Datei die unkomprimiert in 1000 Sektoren passt, komprimiert passt sie in 842 physikalische Sektoren, 158 Sektoren gespart. Aber welche? Nehmen wir an ich will jetzt logischen Sektor 500 lesen, zwölf Bytes davon ändern und den Sektor wieder schreiben. Dabei wird er nach Kompression zufällig größer. Physikalisch liegt der in komprimierter Form vielleicht irgendwo ab Mitte Sektor 421 und ging vorher bis erstes Drittel Sektor 422. Nach der Änderung würde er 8 Byte länger werden. Wo schreibt er den jetzt hin? Und wo merkt er sich daß die zweite Hälfte von 421 und das erste Drittel von 422 jetzt belegter aber unbenutzbarer Platz ist? Und welchen Vorteil soll dieser Monster-Overhead bringen?
Vorteil von Komprimierung: Höhere Schreibrate, niedrigere Flash-Abnutzung. Bernd K. schrieb: > Wie soll das denn eigentlich überhaupt sinnvoll gehen? Nehmen wir an ich > hab ne Datei die unkomprimiert in 1000 Sektoren passt, komprimiert passt > sie in 842 physikalische Sektoren, 158 Sektoren gespart. Aber welche? SSDs sind aufgrund ihrer Arbeitsweise sowieso nicht 1:1 von Blocknummer auf Flash-Platzierung gemappt. Da lässt sich auch Komprimierung mit einbauen. > Nehmen wir an ich will jetzt logischen Sektor 500 lesen, zwölf Bytes > davon ändern und den Sektor wieder schreiben. Dabei wird er nach > Kompression zufällig größer. Physikalisch liegt der in komprimierter > Form vielleicht irgendwo ab Mitte Sektor 421 und ging vorher bis erstes > Drittel Sektor 422. Nach der Änderung würde er 8 Byte länger werden. Flash-Daten werden nicht direkt überschrieben. Das ist technisch unmöglich. Wird ein Sektor neu geschrieben, dann landet er woanders, in einem noch ganz oder teilweise gelöschten Erase-Block. Die Metadaten in der SSD sorgen dafür, dass man ihn dort auch findet. Das skizzierte Problem entfällt deshalb.
:
Bearbeitet durch User
Einen schlechten Ruf verdienten sich die Sandforce-Controller massgeblich aufgrund der teilweise exorbitanten Ausfallrate einiger SSD-Baureihen von OCZ.
A. K. schrieb: > Einen schlechten Ruf verdienten sich die Sandforce-Controller > massgeblich aufgrund der teilweise exorbitanten Ausfallrate einiger > SSD-Baureihen von OCZ. ...und wegen der vielen "Denkpausen", die u.a. wegen dieser Komprimierung auftreten. Und wegen der vielen Ausfälle, nicht nur bei OCZ. Und und und...
A. K. schrieb: > Flash-Daten werden nicht direkt überschrieben. Das ist technisch > unmöglich. Wird ein Sektor neu geschrieben, dann landet er woanders, in > einem noch ganz oder teilweise gelöschten Erase-Block. Die Metadaten in > der SSD sorgen dafür, dass man ihn dort auch findet. Und was ist mit den beiden angefangenen halben Sektoren? > Das skizzierte > Problem entfällt deshalb. Das akzeptiere ich nicht. Erst wenn Du mir erklärst wie man bei obigem Szenario den ganzen entstehenden Verschnitt recyclen kann ohne entweder den ganzen nachfolgenden Rest der Datei ab dem geänderten Sektor neu zu komprimieren oder in erheblich kleineren physikalischen Einheiten zu addressieren ohne daß der dabei entstehende Mehraufwand an Verwaltungsdaten die Komprimierung zunichte macht. Am Besten Du erklärst mir anhand meines Beispiels von oben was dann wirklich in der Festplatte ablaufen würde und wieviel Ersparnis dann tatsächlich noch übrig bleibt (in Anbetracht der zusätzlichen Verwaltungsdaten) wenn frei werdende einzelne Fragmente von Sektoren oder Sektoren beliebig kleiner Länge (nach Kompression) noch sinnvoll den Platz ausfüllen können sollen.
Bernd K. schrieb: > Und was ist mit den beiden angefangenen halben Sektoren? sie werden geschont. Es geht nicht darum mehr Daten auf die Festplatte zu schreiben, sondern möglichst wendig die Flash-Zellen zu belasten. Eventuell wird ja einmal der Sektor von hinten und einmal von vorne gefüllt.
Bernd K. schrieb: > Das akzeptiere ich nicht. Es bleibt dir überlassen, die Erde für eine Scheibe zu halten, die von Elefanten getragen wird. Tatsache ist, dass die Sandforce-Controller recht wirkungsvoll komprimierten. Das wurde nicht nur behauptet, sondern anhand des Verhalten abhängig von der Art der Daten nachgewiesen. > Erst wenn Du mir erklärst Ich habe keinen Einblick in die Firmware dieser Controller. Meine Phantasie reicht aber aus, es für möglich zu halten. Auch ohne dir dafür ein Beispielprogramm zu schreiben. Wobei ich es für durchaus möglich halte, dass bei nichtsequentiellem Schreiben kleiner Einheiten Flash-Controller mit Komprimierung schlechter dastehen als welche ohne, weil vielleicht etwas mehr am Rand darum herum mitgenommen werden muss. Beachte, dass es bei die SSDs mit komprimierenden Controllern nicht darum geht, mehr Daten unterzubringen. die Kapazität wächst dadurch nicht. Aber der mindestens der sequentielle Durchsatz steigt, wenn die Daten gut komprimierbar sind. Entstehende "Löcher" zwischen internen Organisationseinheiten bleiben dabei einfach ungenutzt.
:
Bearbeitet durch User
Bernd K. schrieb: > mir anhand meines Beispiels 1.Bei einem Sack voll Nullen in test.txt schreibt, speichert manches System FAST NICHTS auf die Platte, sondern komprimiert "Deine 1234778789898 Nullen hintereinander" in wenige kb. Erst wenn Du irgendwas.txt >> test.txt anhängst, macht das System eine echte Datei daraus und füllt die Platte. 2.Was ist, wenn die neue Datei nur WENIGE Zeichen beinhaltet und den Cluster nicht ganz füllt? Wird der Rest immer zuverlässig gelöscht?
oszi40 schrieb: > 1.Bei einem Sack voll Nullen in test.txt schreibt, speichert manches > System FAST NICHTS auf die Platte, sondern komprimiert "Deine > 1234778789898 Nullen hintereinander" in wenige kb. Erst wenn Du > irgendwas.txt >> test.txt anhängst, macht das System eine echte Datei > daraus und füllt die Platte. welche System sollen das machen? Spare files sind doch eher die Seltenheit. Da kann man auch nicht einfach 0 reinschreiben, sondern man macht ein Seek zu größer die die Datei bekommen soll. > 2.Was ist, wenn die neue Datei nur WENIGE Zeichen beinhaltet und den > Cluster nicht ganz füllt? Wird der Rest immer zuverlässig gelöscht? meinst du auf Dateisystem ebene oder auf Flash ebene? Im Dateisystem spielt das löschen keine rolle, weil du nicht über das ende einer Datei hinauslesen kannst.
Peter II schrieb: > Spare files sind doch eher die Seltenheit. Nicht für mich. Bei Container-Files von VMs ist das die Regel. Solche Systeme profitieren erheblich davon, dass VMs weit mehr Platz zugeordnet wird, als sie tatsächlich schreiben. Der ungenutzte Rest existiert dann nur in Form adressierbarer aber nicht existenter Blöcke.
A. K. schrieb: > Nicht für mich. Bei Container-Files von VMs ist das die Regel. Solche > Systeme profitieren erheblich davon, dass VMs weit mehr Platz zugeordnet > wird, als sie tatsächlich schreiben. Der ungenutzte Rest existiert dann > nur in Form adressierbarer aber nicht existenter Blöcke. das macht vm-ware aber auch ohne Spare files. Wenn es nicht gerade im SSDs geht, haben spare files auch Nachteile. Sie fragmentieren ja nach Wachstum. Bei uns werden VMs gleich mit voller Größe angelegt damit hat man (angeblich) später eine bessere Performace.
oszi40 schrieb: > Erst wenn Du > irgendwas.txt >> test.txt anhängst, macht das System eine echte Datei > daraus und füllt die Platte. Selbst dann nicht. Spare Files werden nicht "alles oder nichts" verwaltet, sondern in Sektoren, Blöcken oder was auch immer an Einheiten. Hängst du da echte Bytes hinten dran, wird nur dort dieser Platz wirklich geschrieben. Der Rest bleibt unverändert imaginär. Das funktioniert auch unter Windows. Man kann Files beliebiger Grösse anlegen, ohne dass dabei mehr als nur die Metadaten real auf Disk geschrieben werden. Wenn man den nie geschriebenen Kram liest kriegt man Nullen - in sagenhaftem Tempo. Interessant wird das bei Backups. Reine Bytekopien können solche Files auf dem Ziel vollständig aufblasen, wenn das Backup-Programm nicht hinter die Kulissen schaut. Interessanter ist die Frage, ob den imaginären Bereichen solcher Files bereits Platz zugeordnet wird, oder ob das erst dann geschieht, wenn sie tatsächlich Inhalt kriegen. In letzterem Fall kann eine Platte platzen, wenn man alle eigentlich längst eingeplanten Blöcke auch wirklich verwendet.
:
Bearbeitet durch User
Peter II schrieb: > das macht vm-ware aber auch ohne Spare files. Bei NFS Datastores verlässt sich VMware auf die entsprechende Fähigkeit des Storage-Systems.
Peter II schrieb: > Wenn es nicht gerade im SSDs geht, haben spare files auch Nachteile. Sie > fragmentieren ja nach Wachstum. Bei uns werden VMs gleich mit voller > Größe angelegt damit hat man (angeblich) später eine bessere Performace. Es gibt für beide Strategien ein für und wider. Hab beides. Verwendet man VMFS Filesysteme auf klassischen SAN-LUNs, dann kann eine Fragmentierung des Filesystems von VMware schon eine Rolle spielen. Allerdings überschaubar, möchte ich annehmen, denn die Allokationseinheiten von VMFS sind mindestens 1MB gross. Verwendet man allerdings eine NetApp als Datastore, die zwar auch LUNs anbieten kann, aber diese auch bloss als Container auf ihre eigenen Files abbildet, dann fragmentiert das in jedem Fall. Egal ob thin oder thick. Die kann dank ihres COW-Filesystems nicht anders. Andererseits kann sie aber auch im Hintergrund defragmentieren, und da ist es vor grossem Vorteil, wenn die Container-Files der VMs auch tatsächlich einzelne Files auf der NetApp sind. Was bei NFS der Fall ist. Und dann hat eine vollständige Allokation einzig den Vorteil, dass der Datastore nicht platzen kann.
:
Bearbeitet durch User
Peter II schrieb: > das macht vm-ware aber auch ohne Spare files. > > Wenn es nicht gerade im SSDs geht, haben spare files auch Nachteile. Sie > fragmentieren ja nach Wachstum. Bei uns werden VMs gleich mit voller > Größe angelegt damit hat man (angeblich) später eine bessere Performace. "spare files" sind etwas anderes als "sparse files". Sicherlich meinst Du "sparse files", aber dann schreibe den Begriff auch so!
oszi40 schrieb: > 2.Was ist, wenn die neue Datei nur WENIGE Zeichen beinhaltet und den > Cluster nicht ganz füllt? Wird der Rest immer zuverlässig gelöscht? Unter Windows XP gar nicht. Deswegen bietet Eraser die Funktion des Löschens von "Cluster tips". Hast Du die Rechte auf Clusterebene zuzugreifen, kannst Du diese Reste auslesen.
A. K. schrieb: > Interessanter ist die Frage, ob den imaginären Bereichen solcher Files > bereits Platz zugeordnet wird, oder ob das erst dann geschieht, wenn sie > tatsächlich Inhalt kriegen. Schon wenn etwas hinzugefügt wird, kann sich der Zustand wesentlich ändern! Bei meinem Test unter MS NTFS wurde nach dem Anhängen einer 2. winzigen Datei (3buchstaben >> grosse00Leerdatei) SEHR viel mehr Platz auf der Platte als vorher belegt. Deswegen habe ich oben vorsichtig formuliert "je nach System". Ob das überall so ist, habe ich nicht getestet.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.