Am Donnerstag, 5. März 2015, 10:19:01 schrieb alex bachmer: > Servus Martin Hi Alex, > Vielen Dank für den Einwand. > > > Ich würde sowas mit Flash-Speicher ja gar nie niemals machen..... > > > >.....Für mich gibt das für > > > > Flash einfach mal so überhaupt gar keinen Sinn. Und es trägt unnötig > > zum schnelleren Altern des Mediums durch höhere Write Amplification > > Die Karte sollte vernichtet werden...also ich sehe da dann kein Problem Achso, na dann, da habe ich dann doch etwas überlesen, als ich den Thread überflog. Ist vielleicht trotzdem gut, das nochmal erwähnt zu haben, dass Flash mit dd überschreiben oft keine gute Idee ist. > > Nun, wenn die Controller-Firmware vom Flash schlau ist, könnte sie ja > > sagen, sind ja nur nullen. Und dann Discard / Trimming machen. > > > >Allerdings > > > > halte ich das bei SD-Karten eher für unwahrscheinlich. D.h. der obige > > Befehl schafft wahrscheinlich nur die ungünstige Situation, dass die > > > >Flash- > > > > Firmware fortan davon ausgehen *muss*, dass sie keinen der > > >beschriebenen Erase-Blöcke mehr für Garbage Collection verwenden > > darf, weil sie >davon ausgeht, dass wichtige Daten drauf sind > > Ich glaube das ATA TRIM ( wobei es hier eher der SD ERASE Command ist > CMD 38) eh mit nullen überschreibt.In eMMC4. irgendwas gibt es die > "discard" Operation die wohl am ehesten auf TRIM passt die du > meinst.Daher glaub ich > nicht das es stimmt was du schreibst.Zum mal keine Ausgabe von zb. > hdparm vorliegt, dass Trim überhaupt supportet wird( auch wenn die > Wahrscheinlichkeit im Jahr 2015 sehr groß ist und ein Teil im ATA > interface standard ist). Ich bin ziemlich sicher, dass SSDs bei einem Trim die Daten nur vergessen. D.h. intern nur markieren, diese Blöcke kann ich in Zukunft für Garbage Collection wieder verwenden. Und die Firmware beim Zugriff auf einen solchen getrimmten Bereich eben einfach Nullen zurückliefert. Ich bin ziemlich sicher, dass es mit der Intel SSD 320 genauso funktioniert. Anders macht das auch keinen Sinn. Es würde auch keinen Sinn machen, ATA Discard in Linux zu unterstützen, wenn es gegenüber mit Nullen überschreiben, keinen Vorteil bringen würde. Ein weiteres Indiz ist, dass ein fstrim für ein frisches Dateisystem in der Regel nur wenige Sekunden dauert, auch wenn es Gigabyte-weise Daten trimmt. Das schafft auch eine SSD nicht, die so schnell mit Nullen zu überschreiben. Bei einem gealterten BTRFS kann ein fstrim schon mal einige Minuten dauern, das liegt aber daran, dass BTRFS die freien Speicherbereiche erstmal zusammensuchen muss und die dann auch einzeln an die SSD meldet, da erst spätere Versionen des ATA Standards eine Art Bulk Discard unterstützen. merkaba:~> fstrim -v /home /home: 113,3 GiB (121603547136 Bytes) getrimmt hat jetzt so 2-3 Minuten gebraucht. Das reicht für eine SATA-300 SSD immer noch nicht, um diesen Bereich mit Nullen zu überschreiben. Okay, sie könnte hier intern ja schneller werkeln als SATA-300, aber dennoch: Das wären 0,62 GiB/Sekunde bei 180 Sekunden. Nun, das könnte sie schaffen. Aber wie gesagt, bei einem Dateisystem mit weniger fragmentierten freien Speicherplatz geht das *deutlich* schneller. Wie das bei SD-Karten ist? Eine gute Frage. Ich weiß, dass man mit flashbench Erase-Block-Größen raten kann. Ich halte für plausibel, dass Controller auf Schreibschutz schalten, wenn sie glauben dass Flash kann keine weiteren Schreibvorgänge mehr ab. Allerdings: Ich hatte das bei noch keiner SD-Karte. Also wenn ich da nicht regelmäßig drauf schreibe… > Grundsätzlich haben die Vorredner schon recht..kann am Lesegerät > liegen,am Adapter.....,oder,oder...oder auch einfach nur kaputt sein, > wie vermutlich Sven schon recht haben wird. Jup, ist klar. Wenn sie aber eh Write Protected ist, dann hilft das dd auch nicht mehr. Dann helfen nur physikalische Kräfte :) > Sollte ich falsch liegen, freue ich mich natürlich über konstruktive > Kritik. Ich wollte nur generell darstellen, dass ein dd auf Flash eher mit Vorsicht zu genießen ist. In Bezug auf SD-Karten lerne ich gerne auch noch dazu. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.