News Nach 7 Jahren EOL: SATA-SSD-Liebling Crucial MX500 wird eingestellt

Staubwedel schrieb:
Ist aber recht normal. Zwar sind neuere NANDs in der Regel schneller, aber wenn 1 großer NAND statt 2 kleine NANDs verbaut werden kann das nicht ausgeglichen werden.
Das gleiche Prinzip, wie bei der v1 die "halbierten" Ergebnisse der 250 GB.

Die 1000 GB war damals übrigens nicht noch schneller als die 500 GB. Mit der war also die max. Parallelität erreicht.

Nachtrag (ganz vergessen…): Da ich die 250 GB MX500 v1 (übrigens im Juli 2019 gekauft) sowieso neu partitionieren wollte, habe ich sie nach dem platt machen neu gebench und da ich das seit damals etwas verändert habe, sind erst diese Werte direkt mit der 500 GB v3 vergleichbar:
Caramon2 schrieb:
Ergebnis (MiB/s! - MB/s wären ca. 5% höher):

Lesegeschwindigkeit: 541,5 MiB/s
Schreiben SLC-Cache: 406,8 MiB/s (ca. 32 GiB)
Schreiben danach : 300,5 MiB/s
lesen: 541,0 MiB/s
schreiben: 406,1 MiB/s
außerhalb 32,67 GiB SLC-Cache: 204,8 MiB/s

Ich habe die Tabelle entsprechend erweitert: s. Anhang (bei der v1 kommt es später nicht mehr zu diesen Peaks, deshalb habe ich früher abgebrochen)

Staubwedel schrieb:
Für mich ist die mX500 passe seit ich Exemplare hatte die weder mit Crucial Storage Executive noch Parted Magic Secure Erase unterstützten
Irgendwelchen "ominösen" Hersteller-Tools traue ich sowieso nicht: Da hat dann wieder irgendjemand "gedacht" *) und es kommt nur Mist dabei raus. (gebranntes Kind)

*) wie z. B. mal nach einem Verkehrsunfall: "Mein Auto hat ABS: Ich dachte damit ist es egal ob Sand auf der Straße liegt…"

Meine Devise ist "Soll es vernünftig werden: Mach es selbst!" :)

Secure-Erase z. B. so:
Code:
lw=/dev/sdX
sudo hdparm -I $lw|grep -ie frozen -e trim
sync;sudo hdparm --security-set-pass NULL $lw && time sudo hdparm --security-erase NULL $lw
Das frickelige dabei ist, dass die SSD "not frozen" sein muss, die Laufwerke beim booten aber auf "frozen" gesetzt werden.

Da es mir etwas zu heikel ist, im laufenden Betrieb den Stromstecker anzuschließen, ziehe ich einfach das SATA-Kabel ab, schalte den PC ein und wenn er gebootet ist, schließe ich es wieder an = "not frozen". - Btw: Wie macht man das bei M.2? ;)

Aber ein Secure-Erase ist normalerweise gar nicht nötig, da auch ein einfaches sudo blkdiscard -fv $lw (die Variable auf's richtige Laufwerk gesetzt) das komplette Laufwerk löscht - und das sogar schonender:

Meine erst SSD war eine 250 GB BX100 und die zeigte bei SMART noch die echten Flash-Writes an:

Bei einem Secure-Erase wurde die vollständige Kapazität geschrieben, d. h. alle Flashzellen wurden gelöscht: Unabhängig davon, ob sie überhaupt Daten enthalten. "blkdiscard" löscht dagegen nur die Zellen, die nicht sowieso schon (durch Trim) gelöscht wurden.

Je nachdem wie die SSD sich verhält (manche zeigen nach dem trimmen sofort Nullen, andere setzen Trim verzögert um) muss man ggfs. einige Minuten warten und kann es dann mit sudo hexdump -C $lw kontrollieren.

Ich das Laufwerk vollständig leer, startet es so und läuft bis zum Ende durch, ohne dass neues hinzukommt:
Code:
$ hexdump -C sdc
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
40000000
(ich hatte das mit einer 1G Testdatei in der RAM-Disk simuliert: dd if=/dev/zero of=sdc bs=1G count=1)

Übrigens braucht man dazu kein installiertes Linux: Das funktioniert mit jedem geläufigen Linux-Livesystem, da obige Tools normalerweise vorinstallierte "Hausmittelchen" sind.

Welches "/dev/sdX" das richtige ist, kann man am einfachsten mit "Laufwerke" (so ist das Programm in deutsch benannt - auch deshalb die Empfehlung zum deutschen LMDE) nachsehen, oder wenn es nicht vorinstalliert ist, mit "GParted".

WICHTIG: Nach jedem booten neu nachsehen, da sich die Reihenfolge ändern kann: Z. B. kann ein erst nachträglich angeschossenes USB-Laufwerk nach einem Reboot plötzlich/dev/sda sein und die anderen einen Buchstaben nach hinten verschieben.



Tatsächlich durchgeführter Secure-Erase:

Da ich die "schrottige" 512 GB Verbatim nicht mehr brauche, habe ich sie secure-erased, um sie einzumotten und kontrolliert, ob sie wirklich leer ist:
Code:
$ lw=/dev/sdc

$ sudo hdparm -I $lw|grep -ie frozen -e trim
       *    Data Set Management TRIM supported (limit 8 blocks)
       *    Deterministic read ZEROs after TRIM
    not    frozen

$ sync;sudo hdparm --security-set-pass NULL $lw && time sudo hdparm --security-erase NULL $lw
security_password: ""

/dev/sdc:
 Issuing SECURITY_SET_PASS command, password="", user=user, mode=high
security_password: ""

/dev/sdc:
 Issuing SECURITY_ERASE command, password="", user=user

real    0m5,380s
user    0m0,007s
sys    0m0,003s

$ time sudo hexdump -C $lw
performance
4000000
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
773c256000

real    17m14,864s
user    0m0,007s
sys    0m0,003s
 

Anhänge

Zuletzt bearbeitet: ("echter" Secure-Erase nachgetragen)
  • Gefällt mir
Reaktionen: Staubwedel
Staubwedel schrieb:
Donnerwetter, dann muß dein alter Läppi ein Überhammer im Jahre 2012 gewesen sein
Ich bin zwar nicht lorpel,
schreibe diese Nachricht aber gerade auch auf einem Notebook mit der Technik von 2012 und ich kann mich über die Leistung nicht beschweren.
Ich habe hier noch ein paar Notebooks mit einer Sandy-Bridge bzw. Ivy-Bridge CPU.
die 2011, bzw. 2012 vorgestellt wurden.
4 Kerne, 8 Threads in einem Notebook, mit einer SSD, das passt eigentlich.
Ja, ich nutze neben Win hauptsächlich Linux, aber ich kann mich selbst bei Nutzung von Win 10 über die Leistung nicht beschweren. Allerdings möchte ich anmerken, dass man bei einem Dualcore durchaus spürbare Leistungsuntschiede zum Quad-Core merkt, aber nutzen kann man dies auch noch (halt mit etwas mehr Geduld).

Daher finde ich es umso bedauerlicher, dass ich dann ab in etwa 10 Monaten mich von Win auf diesen Geräten verabschieden werden, auf dem Krampf irgendwie Win 11 auf den Kisten ans laufen zu bekommen, fehlt mir das Interesse, da macht Linux einfach weniger Stress.


Um noch etwas zum Thema beizutragen, ich habe zwar nie eine Crucial MX500 verwendet, ich hatte aber mal eine Crucial M550 mSata SSD im Einsatz, die aber im Betrieb sehr warm wurde.
Seit dem bin ich bei 2,5" (und mSATA) SSDs bis jetzt bei Samsung geblieben und kann mich nicht beschweren.
 
Caramon2 schrieb:
Irgendwelchen "ominösen" Hersteller-Tools traue ich sowieso nicht: Da hat dann wieder irgendjemand "gedacht" *) und es kommt nur Mist dabei raus. (gebranntes Kind)

Sollten nicht gerade die funktionieren?

Bei älteren Version der MX500 war das auch kein Problem, also FW-abhängig.

Caramon2 schrieb:
Da es mir etwas zu heikel ist, im laufenden Betrieb den Stromstecker anzuschließen, ziehe ich einfach das SATA-Kabel ab, schalte den PC ein und wenn er gebootet ist, schließe ich es wieder an = "not frozen". - Btw: Wie macht man das bei M.2?

Bei fest eingebauten SATA-SSDs hat man mit Parted Magic die Möglichkeit den PC kurz auf Standby zu setzen, nach ein paar Sekunden springt er wieder an und die Laufwerke sind unlocked.

Ich tippe mal den Freeze gibt es bei NVME einfach nicht, bisher konnte ich alle NVME, zumindest mit Boards ab 2020, direkt mit Parted Magic löschen. Mit einem älteren Gigabyte X370 OEM-Board mußte ich allerdings auch mal mit Parted Magic in den Standby.

Mit neueren Asrock und neuen Asus-Boards kann man das meist direkt übers UEFI machen, bei SATA muß man evtl nach Auslösen des SE nochmal ins UEFI und nochmal ausführen.

Caramon2 schrieb:
Bei einem Secure-Erase wurde die vollständige Kapazität geschrieben, d. h. alle Flashzellen wurden gelöscht: Unabhängig davon, ob sie überhaupt Daten enthalten. "blkdiscard" löscht dagegen nur die Zellen, die nicht sowieso schon (durch Trim) gelöscht wurden.

Bin mir nicht sicher ob das bei SSDs nötig ist. Ich kämpfe beruflich manchmal mit Software die was auf der SSD/HDD zurückläßt, was zumindest mit Quick Format bei HDD nicht verschwindet. Mit Secure Erase aber kein Problem, selbst wenn er wie bei Samsung SATA-SSDs keine 3s dauert.

Ich hatte mal eine Corsair 240GB mit Phison-Controller, da wurden über das Corsair-Tool wirklich alle Zellen gelöscht. Aber das war die Ausnahme. Bei den 240GB wars erträglich, aber heutige normale Größen wie 2TB möchte ich so nicht löschen

Caramon2 schrieb:
Übrigens braucht man dazu kein installiertes Linux: Das funktioniert mit jedem geläufigen Linux-Livesystem, da obige Tools normalerweise vorinstallierte "Hausmittelchen" sind.

Das mit Linux wollte ich oben monieren, aber Parted Magic booten und damit Secure Erase ist schneller und komfortabler.

SchwarzesLoch schrieb:
4 Kerne, 8 Threads in einem Notebook, mit einer SSD, das passt eigentlich.

Nicht zu vergleichen mit einem 2-Kern-Celeron ;)

SchwarzesLoch schrieb:
Um noch etwas zum Thema beizutragen, ich habe zwar nie eine Crucial MX500 verwendet, ich hatte aber mal eine Crucial M550 mSata SSD im Einsatz, die aber im Betrieb sehr warm wurde.

Kann ich nichts dazu sagen, aber die MX500 hat keinerlei Temperaturprobleme. mSATA generell ist ein andere Fall, das Format ist da anfälliger.

Ich hab NVME die auch beim Lesen nach einigen Minuten die 70° überschreiten
 
  • Gefällt mir
Reaktionen: Caramon2
SchwarzesLoch schrieb:
Daher finde ich es umso bedauerlicher, dass ich dann ab in etwa 10 Monaten mich von Win auf diesen Geräten verabschieden werden, auf dem Krampf irgendwie Win 11 auf den Kisten ans laufen zu bekommen, fehlt mir das Interesse, da macht Linux einfach weniger Stress.
Müssen muss man nicht. Per offiziellen "Trick" (z. B. per Ventoy) lässt sich WinXI ja auch auf älteren PCs installieren.

MS warnt zwar immer wieder, dass das ach so unsicher ist und es irgendwann keine Updates mehr gibt, aber inzwischen erscheint mir das genauso ernsthaft gemeint, wie damals, dass man den WinVII-Key nur wenige Monate lang für WinX nutzen kann.

Falls die es sich in irgendwann doch anders überlegen, kannst du dir immer noch einen "kompatiblen" PC zulegen.

Staubwedel schrieb:
Bei fest eingebauten SATA-SSDs hat man mit Parted Magic die Möglichkeit den PC kurz auf Standby zu setzen, nach ein paar Sekunden springt er wieder an und die Laufwerke sind unlocked.
Ach richtig, da war ja mal was: Bei meinem vorherigen Board konnte ich das auch lösen, indem ich den PC in Susprnd2RAM geschickt habe. Aber bei meinem aktuellen Board funktioniert S2R nichts, weil lt. Protokoll der onboard-USB3-Controller (ASmedia) das blockiert: Egal ob und welches Windows oder Linux.

Staubwedel schrieb:
Bin mir nicht sicher ob das bei SSDs nötig ist. Ich kämpfe beruflich manchmal mit Software die was auf der SSD/HDD zurückläßt, was zumindest mit Quick Format bei HDD nicht verschwindet. Mit Secure Erase aber kein Problem, selbst wenn er wie bei Samsung SATA-SSDs keine 3s dauert.
Die Zeit sagt nichts aus. Bei der BX100 hat das auch nur ca. 5 Sek. gedauert. Trotzdem gab es die volle Kapazität mehr FlashWrites.

Kann inzwischen natürlich anders geregelt sein. Mangels Anzeige der tatsächlichen FlashWrites kann man es ja nicht mehr kontrollieren.
 
Staubwedel schrieb:
Nicht zu vergleichen mit einem 2-Kern-Celeron ;)
Definitiv nicht!


Caramon2 schrieb:
Müssen muss man nicht. Per offiziellen "Trick" (z. B. per Ventoy) lässt sich WinXI ja auch auf älteren PCs installieren.

MS warnt zwar immer wieder, dass das ach so unsicher ist und es irgendwann keine Updates mehr gibt, aber inzwischen erscheint mir das genauso ernsthaft gemeint, wie damals, dass man den WinVII-Key nur wenige Monate lang für WinX nutzen kann.

Falls die es sich in irgendwann doch anders überlegen, kannst du dir immer noch einen "kompatiblen" PC zulegen.
Ja, ich weiß, dass das geht, auch selbst mal mit experimentiert und funktioniert auch.
Aber ist mir am Ende zu nervig, mich damit rum zu schlagen.

Dafür habe ich ein Notebookj von meinem Arbeitgeber, auf dem Win 11 auch ohne Verränkung läuft, damit gebe ich mich zufrieden.

Für den Rest bleibe ich bei Linux
 
  • Gefällt mir
Reaktionen: Caramon2
Caramon2 schrieb:
Heute ist sie sie angekommen:
Code:
[  107.390805] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[  107.390931] ata4.00: supports DRM functions and may not be fully accessible
[  107.390937] ata4.00: ATA-10: CT500MX500SSD1, M3CR046, max UDMA/133
[  107.390973] ata4.00: 976773168 sectors, multi 1: LBA48 NCQ (depth 32), AA
[  107.391742] ata4.00: Features: Trust Dev-Sleep
[  107.391863] ata4.00: supports DRM functions and may not be fully accessible
[  107.392611] ata4.00: configured for UDMA/133
[  107.392859] scsi 3:0:0:0: Direct-Access     ATA      CT500MX500SSD1   046  PQ: 0 ANSI: 5
[  107.393531] sd 3:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[  107.393541] sd 3:0:0:0: [sdc] 4096-byte physical blocks
[  107.393570] sd 3:0:0:0: [sdc] Write Protect is off
[  107.393577] sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[  107.393613] sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  107.393705] sd 3:0:0:0: [sdc] Preferred minimum I/O size 4096 bytes
[  107.421121] sd 3:0:0:0: [sdc] supports TCG Opal
[  107.421135] sd 3:0:0:0: [sdc] Attached SCSI disk
Quasi zum Abschluss noch, wie ich mein System jetzt eingerichtet habe:

Die 250 GB MX500 v1 habe ich mir damals vor allem gekauft, um die Opal-Verschlüsselung zu nutzen, da sie ansonsten gegenüber meiner vorherigen 250 GB BX100 (MLC, kein SLC-Cache) weder in Haltbarkeit, noch Dauerschreibleistung ein Vorteil war: Nach knapp 33 GiB sinkt die Schreibgeschwindigkeit auf ca. 204 MiB/s, während die BX100 die volle Kapazität durchgehend mit ca. 336 MiB/s beschreiben kann.

Unten sind meine Notizen von damals, mit denen ich jetzt auch bei der 500 GB MX500 v3 Opal mit dem selben Passwort aktiviert habe, damit beim ersten booten ins PBA beide entsperrt werden. - Da ich von der 500 GB nicht booten können muss, habe ich das PBA dort nicht installiert (unten die Zeilen 22 und 23 ausgelassen).

So sehen beide vor dem entsperren aus:

Opal_0.png
Opal_1.png

Wie das booten ins PBA aussieht, habe ich per VM nachgestellt und aufgenommen: s. Anhang

Das entsperren funktioniert aus der VM heraus nicht, aber das kann ich bei meinem Zweitsystem (auf ext. SSD - jetzt die 512 GB Verbatim), von dem aus ich Opal einrichte, auch per Komandozeilentool machen:
Code:
$ linuxpba
DTA LINUX Pre Boot Authorization
Please enter pass-phrase to unlock OPAL drives: ********
Scanning....
- 01:47:19.341 INFO: MBRDone set on
- 01:47:19.613 INFO: LockingRange0 set to RW
Drive /dev/sdX   CT250MX500SSD1                           is OPAL Unlocked  
- 01:47:19.923 INFO: MBRDone set on
- 01:47:20.192 INFO: LockingRange0 set to RW
Drive /dev/sdb   CT500MX500SSD1                           is OPAL Unlocked  
Drive /dev/sdc   Verbatim Vi550 S3                        not OPAL

Anschließend:

Opal_2.png
Opal_3.png

Beide SSDs lassen sich ab dann normal nutzen, unabhängig von Reboots oder auch Hard-Resets. Erst wenn man sie vom Strom trennt (also den PC ausschaltet), sperren sie sich wieder.



Code:
# Voraussetzung:

sudo nano /etc/default/grub
# bei "GRUB_CMDLINE_LINUX" hinzufügen: " libata.allow_tpm=1"
sudo update-grub

+ Neustart

# Das OPAL-Laufwerk:
lw=/dev/sdX

# Kontrolle:
sedutil-cli --isValidSED $lw
# muss "-2-" sein

linuxpba | grep $lw  # Passwort "debug" blind eingeben: Bei Falscheingabe sofortiger Neustart!
# muss "is OPAL NOT LOCKED" sein

sedutil-cli --initialsetup debug $lw
sedutil-cli --setlockingrange 0 lk debug $lw
sedutil-cli --enablelockingrange 0 debug $lw
sedutil-cli --setmbrdone off debug $lw
sync;time sedutil-cli --loadpbaimage debug BIOS32-1.15.1.img $lw

linuxpba | grep $lw  # Passwort "debug" blind eingeben: Bei Falscheingabe sofortiger Neustart!
# muss "is OPAL Unlocked" sein

# Endgültiges Passwort setzen (*PBA nutzt US-Tastatur-Layout!*):
sedutil-cli --setsidpassword debug [Passwort mit us-Layout] $lw
sedutil-cli --setadmin1pwd debug [Passwort mit us-Layout] $lw

# kontrollieren, ob Passwort funktioniert:
sedutil-cli --setmbrdone on [Passwort mit us-Layout] $lw

# Your drive in now using OPAL locking.
# You now need to COMPLETELY POWER DOWN YOUR SYSTEM
# This will lock the drive so that when you restart your system it will boot the PBA.
 

Anhänge

  • PBAboot.mp4
    34,4 KB
Zuletzt bearbeitet:
Zurück
Oben