staging.inyokaproject.org

Angepasst auf 350. Bei 250 sind die Bilder, auf die es wirklich ankommt, nicht gut genug sichtbar. Genau diese Bilder können viele Euros kosten. Sie sollten unmissverständlich lesbar sein. Daher habe ich ein bisschen aufgerundet, 350 für alle Bilder ausgewählt.

Hallo,

die Bilder sind immer lesbar - wenn du drauf klickst, bekommst du immer die Originalgröße wie von dir hochgeladen.

Die Nummerierung stimmt noch noch nicht, 1. kommt viele zu oft vor...

Gruß, noisefloor

Nagut, dann stelle ich sie wieder auf 250. Aber ich stehe gerade auf dem Schlauch, ich weiß nicht, was du mit der Nummerierung meinst? Kannst du mir ein zwei Bilder nocheinmal beispieleditieren, bitte?

▶ Wiki/Sandkasten/a/revision/958974

behandelt die Vorschläge

1. Bildersammlung

2. Nummerierung mit Bild-Unterbrechungen

Jetzt klarer?

Gruß BillMaier

Ps. Gibts auch mit größeren Bildern

Ich glaube jetzt hab ichs. Könnt drüberschauen.

Von meiner Seite aus gibt es nichts hinzuzufügen.. außer einem Screenshot des MSi B450 Tomahawk vielleicht? Aber dessen Secure-Erase-Funktion kann ich zur Zeit nicht in Action dokumentieren.

Erstens: Ich bin FERTIG und was passiert nun?

Zweitens: getestet mit 16.04. Quelle: https://forum.ubuntuusers.de/topic/dev-sda3-requires-a-manual-fsck/3/

Jetzt ist das Wikiteam dran. Danke für die Erinnerung.

Gruß BillMaier

Hallo,

hat ein wenig länger gedauert (...), aber der Artikel ist wieder im Wiki. Danke für die Überarbeitung!

Gruß, noisefloor

Der lag noch in der Gruft, aber die Geister ließen ihn heute endlich frei. 😉

oh, es gibt ein forum zum artikel. dann poste ich meine anmerkungen einfach hier:

"Vor einer Partitionierung und einem Formatieren sollte man die SSD ebenfalls einem „Secure Erase“ unterziehen. Damit werden alle Blöcke der SSD vom Controller gelöscht, was die Performance der SSD steigert."

meines wissens werden nicht alle blöcke gelöscht, sondern vom controller als frei markiert. flash-zellen kann man nur löschen, indem man sie überschreibt. wenn der controller nach dem secure-erase wieder wahlfrei auf flashzellen zugreifen kann, beschleunigt das das schreiben, weil nicht zuvor blöcke zusammengefaßt und umkopiert werden müssen.

"Löschen im Terminal mit hdparm: Aus einer Konsole heraus über hdparm. Kann wegen des Freeze-Status Problems schwierig sein."

mit manchen neuen sata-ssds funktioniert hdparm nicht mehr (da sollte man das hersteller-tool benutzen, z.b. Micron’s Storage Executive software für ssds von micron und crucial, https://www.micron.com/resource-details/c2014714-450c-4ebf-b9a5-032e3bb4a61a), bei nvme-ssds sowieso nicht (hdparm setzt auf ata-kommandos).

schöne grüße!

Quadratschädel schrieb:

meines wissens werden nicht alle blöcke gelöscht, sondern vom controller als frei markiert. flash-zellen kann man nur löschen, indem man sie überschreibt.

Das Thomas-Krenn-Wiki formuliert es auch als Löschen. Allerdings steht dort auch, dass das nach einem ATA-Trim nicht mehr notwendig ist, im entsprechenden Artikel https://www.thomas-krenn.com/de/wiki/ATA_Trim dort steht aber, dass die Daten nicht gelöscht werden...

Quadratschädel schrieb:

flash-zellen kann man nur löschen, indem man sie überschreibt.

Hmmm, das ist eigentlich bei Festplatten so. Da kann man nur lesen und schreiben. Und löschen dann eben nur durch überschreiben.

Bei Flashzellen gibts tatsächlich eine Löschoperation. Die notwendig ist, um die Zelle wieder beschreiben zu können. Überschreiben ohne zu Löschen geht nicht.

http://codecapsule.com/2014/02/12/coding-for-ssds-part-3-pages-blocks-and-the-flash-translation-layer/ ( basic operations: read write erase )

Löschen ist langsam, um eine Größenordnung langsamer als eine bereits gelöschte Zelle zu beschreiben. Für Performanz ist es daher interessant, freigegebene Zellen tatsächlich zu löschen.

Theoretisch sollte man sich mit dem Secure Erase nie rumschlagen müssen, blkdiscard reicht, einmal TRIM und die Daten siehst du nie wieder.

Was die SSD wirklich macht kann man halt leider nur schwer nachkontrollieren. Von außen betrachtet ist das eine Black Box. Genauso wie das ganze Secure Erase auch... und wie man merkt kann man sich auf in Hardware gegossene Mechanismen einfach nicht verlassen (so wie die kürzlich entdeckten Schwachstellen in der SED-Verschlüsselung). Wenn du Daten handfest nachweislich gelöscht haben willst, landet man daher auch bei SSD wieder beim klassischen Überschreiben-mit-Zufallsdaten.

wenn der controller nach dem secure-erase wieder wahlfrei auf flashzellen zugreifen kann, beschleunigt das das schreiben, weil nicht zuvor blöcke zusammengefaßt und umkopiert werden müssen.

Das ist ja nur ein Teil davon, der andere Teil ist das (hoffentlich) eben immer genug freie / tatsächlich gelöschte Zellen zur direkten Verwendung da sind, auf die man nicht erst warten muss...

# hdparm --user-master u --security-set-pass GEHEIM /dev/sdc
# time hdparm --user-master u --security-erase GEHEIM /dev/sdc

habe ich getestet auf Ubuntu 20.04, da meine WD Red nun die ersten Sektorfehler bekam.

Bei diesem Artikel möchte ich aus ergonomischen Gründen

1. die Warnung-Box zu „secure erase löscht wirklich alles“ degradieren zur Hinweis-Box und

2. die Hinweis-Box „secure-erase am nicht-SATA-Anschluss kann das Gerät bricken“ zur Warnung-Box aufwerten.

Begründung: Wer löschen will, weiß vermutlich, dass danach alles weg ist. Dagegen ist die Gefahr zum bricken nicht offensichtlich und außerdem der größere Schaden im Vergleich zu einem Datenverlust.

Änderung OK?