Test Drei externe SSDs im Test: Lexar SL500 Portable vs. Kingston XS2000 & XS1000

Clark79 schrieb:
Empfehlungen für jeweilige Cases
Was ASM2364 und 20Gbps angeht - fast alle Usb3.2 Gen2x2 Cases seit Anfang. Ja, es gibt seit einem halben Jahr auch Gen2x2-Brückenchips von JMicron und Realtek - alle zusätzlich mit SATA-Unterstützung (was kaum einen Sinn ergibt, denn so einen Case kauft man mit Fleiß um eine NVMe-SSD zu nutzen. Kein B-Key/Sata (was bei 20Gbps-Cases immer noch zu 99% ist) -> Asmedia = leicht zu erkennen.
Und was ASM235CM angeht -> vor allem von Ugreen in allen letzten Modellen eingesetzt. Bestes Gehäuse für 2,5"-SATA mit dieser Brücke -> Ugreen CM300. Habe paar Stück ganz günstig bei Release geschnappt, sind jetzt aber mind. doppelt so teuer und Alu muss nicht unbedingt sein - SATA-SSDs überhitzen nicht wirklich.
Also kannst getrost eine billigere Plastik-Variante nehmen, Innereien sind momentan identisch (früher in den gleichen Cases wurden ältere Chips eingesetzt - also keine Ladenhüter in kleinen Shops kaufen - am besten einfach im Online-Shop des Herstellers, es gibt oft Sales). Geschwindigkeiten sind kaum schlechter, als intern über SATA (schlechte Bewertungen sind meist von Noobs mit alten PCs am USB3.0 entstanden), hier als Beispiel mit einer 870Evo:
1716994029369.png
 
  • Gefällt mir
Reaktionen: Benjamin_Blume und Clark79
Jo Lexar ist eben das neue Samsung!
 
  • Gefällt mir
Reaktionen: Benjamin_Blume
Ich habe mir vorgestern die 2 TB XS1000 bestellt: Ausschlaggebend war für mich das kompakte Gehäuse, da sie sogar in die kleine USB-Stick-Tasche vorne rechts bei Jeans passt.

Ich werde sie LUKS-verschlüsselt formatieren, da sie als zusätzliche Sicherung aller meiner Daten (ca. 1 TB) gedacht ist, die ich jederzeit aktualisieren kann und einfach mitnehme, wenn ich die Wohnung verlasse:

Egal was in meiner Abwesenheit hier passiert (z. B. Wohnungsbrand: da ich in der Dachwohnung wohne, ist es egal in welcher es beginnt), ich habe meine Daten sicher dabei und da ich es als bootfähige Kopie meines Produktivsystem erstellen werde, kann ich es sofort an jedem x84-64 PC booten, der im BIOS-Modus/CSM von USB booten kann.

Ich komme so über meine gewohnte Arbeitsumgebung sofort z. B. an meine Versicherungsunterlagen, Kontodaten, Passwörter, usw.
 
Ich habe die 2 TB XS1000 gebencht und komme auf andere Ergebnisse: Offenbar wurde sie etwas überarbeitet.

Die Lesegeschwindigkeit ist über die gesamte Kapazität ziemlich konstante 804-805 MB/s, aber schreiben tut sie nur mit schwankenden 530-550 MB/s.

Dafür war der SLC-Cache erst nach 372 GiB voll. - Ich vermute, dass vorher schon etwas vom SLC-Cache geschrieben wurde, wodurch er zwar etwas langsamer war, dafür aber deutlich länger reichte. Bei 472 GiB habe ich abgebrochen, da ich sie nicht unnötig "quälen" wollte.

Auch sank die Schreibgeschwindigkeit nicht schlagartig auf den langsamen Wert (wie bei allen anderen bisher von mir getesteten SSDs), sondern etwas verzögert.

Anbei eine Tabelle mit den ermittelten Werten + Diagramm des Einbruchs ab 372 GiB und wie ich gebencht habe.
 

Anhänge

Caramon2 schrieb:
Ich habe mir vorgestern die 2 TB XS1000 bestellt:
Und schon kaputt!

Heute bin ich endlich dazu gekommen sie einzurichten, aber nachdem ca. ein halbes TB drauf kopiert war, brach es plötzlich ab und die SSD war nicht mehr ansprechbar.

Ich reboote den PC, aber beim POST bleibt er hängen. - Das gleiche nach einem Hardreset.

Ich ziehe die SSD ab + Hardreset und der PC fährt hoch.

Ich schließe die SSD wieder an, alles scheint in Ordnung zu sein: Die Systempartition lässt sich normal öffnen, xfs meldet clean mount, alles scheint noch da zu sein, aber als ich sie trimmen will, hagelt es im parallel laufenden "dmesg -w" Fehlermeldungen.

Die Partition lässt sich aber noch normal aushängen, ich reboote nochmal, aber der PC bleibt mit der SSD (egal an welchem der beiden USB3-Controller des Board sie angeschlossen ist) wieder beim POST hängen (auch kurz ausschalten + Steckdosenleiste aus) ändert nichts.

Schließe ich sie nach dem booten an, wirkt alles normal, aber die verschlüsselte Homepartition kann ich zwar entsperren, aber nicht einhängen: Da die SSD sich ja beim drauf kopieren verabschiedet hat, will xfs das Jounal wiederherstellen, was aber nicht möglich ist:

Auf die komplette SSD lässt sich nur readonly zugreifen: Nicht mal ein Secure-Erase ist noch möglich!

Nur manuell mit der Mount-Option "norecover" kann ich die Homepartition einhängen (daher weiß ich wie viel drauf kopiert wurde).

Gut dass die Homepartition verschlüsselt ist, sonst wäre das echt ein Problem, weil meine sämtlichen Daten vom PC schon drauf sind (Bankverbindung, Kontoauszüge, Passwörter, usw.): Die könnte ich so doch nicht zurück schicken!

Der Fehler passierte beim kopieren des Videoarchivs. - Von einer 1 TB HD, die durchschnittlich ca. 150 MB/s liefert: Die SSD war beim schreiben also alles andere als am Anschlag und fühlte sich auch nur lauwarm an.

Morgen - d. h. heute werde ich bei Reichelt anrufen, was die dazu sagen: Übrigens meine erste Bestellung dort. Fängt also richtig gut an. :)
 
Moin.

Da sie intern vielleicht doch zu heiß wurde (SMART lässt sich leider nicht auslesen) und erst länger abkühlen musste, habe ich es eben nochmal versucht.

PC gebootet und die SSD erst dann angeschlossen, dabei keine Auffälligkeiten:
Code:
[   49.424534] usb 9-1.3: new SuperSpeed USB device number 4 using xhci_hcd
[   49.448985] usb 9-1.3: New USB device found, idVendor=0951, idProduct=1780, bcdDevice= 1.00
[   49.448997] usb 9-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   49.449003] usb 9-1.3: Product: XS1000
[   49.449008] usb 9-1.3: Manufacturer: Kingston
[   49.449012] usb 9-1.3: SerialNumber: 50026B72833E9A65
[   49.488949] usbcore: registered new interface driver usb-storage
[   49.504234] scsi host6: uas
[   49.504430] usbcore: registered new interface driver uas
[   49.507049] scsi 6:0:0:0: Direct-Access     Kingston XS1000           1000 PQ: 0 ANSI: 6
[   49.528289] sd 6:0:0:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[   49.597269] sd 6:0:0:0: [sdc] Write Protect is on
[   49.597279] sd 6:0:0:0: [sdc] Mode Sense: 03 00 80 08
[   49.598262] sd 6:0:0:0: [sdc] No Caching mode page found
[   49.598271] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[   49.675627]  sdc: sdc1 sdc2 sdc3
[   49.675987] sd 6:0:0:0: [sdc] Attached SCSI disk
Dann wollte ich die Partitionstabelle ("#" = als root) überschreiben:
Code:
# lw=/dev/sdc;dd if=/dev/zero of=$lw oflag=direct status=progress bs=1M count=1
dd: '/dev/sdc' konnte nicht geöffnet werden: Das Dateisystem ist nur lesbar
Dto. bei blkdiscard ("-fv" = force+verbose)
Code:
# blkdiscard -fv $lw
blkdiscard: /dev/sdc kann nicht geöffnet werden: Das Dateisystem ist nur lesbar
Und beim Secure-Erase hatte ich natürlich auch nichts anderes erwartet:
Code:
# hdparm -I $lw|grep -ie frozen -e trim
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       *    Data Set Management TRIM supported (limit unknown)

# hdparm --security-set-pass NULL $lw 
security_password: ""

/dev/sdc:
 Issuing SECURITY_SET_PASS command, password="", user=user, mode=high
The running kernel lacks CONFIG_IDE_TASK_IOCTL support for this device.
SECURITY_SET_PASS: Invalid argument
"dmesg" zeigte:
Code:
[  191.094277] sd 6:0:0:0: [sdc] tag#26 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT 
[  191.094291] sd 6:0:0:0: [sdc] tag#26 CDB: ATA command pass through(16) 85 0a 06 00 00 00 01 00 00 00 00 00 00 40 f1 00
[  191.094341] xhci_hcd 0000:02:00.0: ERROR Transfer event for unknown stream ring slot 5 ep 1
[  191.094354] xhci_hcd 0000:02:00.0: @00000000bfffc540 00000000 00000000 1a000020 05028000
[  191.110890] scsi host6: uas_eh_device_reset_handler start
[  191.188193] usb 9-1.3: reset SuperSpeed USB device number 4 using xhci_hcd
[  191.213718] scsi host6: uas_eh_device_reset_handler success
Der eigentliche Secure-Erase hat dann natürlich auch nicht funktioniert:
Code:
# hdparm --security-erase NULL $lw
security_password: ""

/dev/sdc:
 Issuing SECURITY_ERASE command, password="", user=user
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Als es nach fast einer halben Stunde immer noch nicht weiter ging, habe ich die SSD wieder abgezogen:
Code:
The running kernel lacks CONFIG_IDE_TASK_IOCTL support for this device.
SECURITY_ERASE: Invalid argument
"dmesg":
Code:
[ 1929.856488] usb 9-1.3: USB disconnect, device number 4
[ 1929.856681] xhci_hcd 0000:02:00.0: ERROR Transfer event for unknown stream ring slot 5 ep 1
[ 1929.856688] xhci_hcd 0000:02:00.0: @00000000bfffc7e0 00000000 00000000 1a000000 05028000
[ 1929.856971] sd 6:0:0:0: [sdc] tag#25 uas_zap_pending 0 uas-tag 1 inflight: CMD 
[ 1929.856979] sd 6:0:0:0: [sdc] tag#25 CDB: ATA command pass through(16) 85 0a 06 00 00 00 01 00 00 00 00 00 00 40 f4 00
Nach dem wieder anschließen war alles wie diese Nacht.

Die Systempartition ließ sich öfnen, die verschlüsselte Homepartition zwar entsperren, dann aber wieder nicht öffnen, da das "recovery" nicht umgesetzt werden konnte:
Code:
[ 2071.418507] XFS (sdc2): Mounting V5 Filesystem 3bab5d41-420e-4104-bcdc-83dee87beccf
[ 2071.434528] XFS (sdc2): Ending clean mount

[ 2087.152219] Key type encrypted registered

[ 2089.457562] XFS (dm-0): Mounting V5 Filesystem aa99f57f-a14f-4d38-824b-01154de5f098
[ 2089.499641] XFS (dm-0): recovery required on read-only device.
[ 2089.499648] XFS (dm-0): write access unavailable, cannot proceed.
[ 2089.499650] XFS (dm-0): log mount/recovery failed: error -30
[ 2089.499725] XFS (dm-0): log mount failed

LWa.png
LWb.png
 
  • Gefällt mir
Reaktionen: massaker
Um nichts zu übersehen, habe ich die Allwissende Müllhalde™ (aka das Internet - kennt jemend noch die Fraggles) gefragt. Genauer gesagt die "Browser-KI" vom Android-Opera, das tatsächlich einige interessante Möglichkeiten geliefert hat, aber alle erfolglos.

Also mit an Sicherheit grenzender Wahrscheinlichkeit :) tatsächlich ein Hardware-Defekt:
Andreas:
Weshalb ist meine Kingston XS 1000 plötzlich immer schreibgeschutzt und lässt sich nicht mal mehr löschen?
Aria:
Es gibt mehrere mögliche Gründe, warum deine Kingston XS 1000 plötzlich schreibgeschützt ist und sich nicht mehr löschen lässt. Hier sind einige häufige Ursachen und mögliche Lösungen:

Mögliche Ursachen

Physischer Schreibschutz: Überprüfe, ob der USB-Stick einen physischen Schreibschutzschalter hat, der aktiviert sein könnte.
Dateisystemfehler: Das Dateisystem könnte beschädigt sein, was zu Schreibschutzproblemen führt.
Viren oder Malware: Schadsoftware könnte den Schreibschutz aktivieren, um die Daten zu schützen.
Betriebssystemeinstellungen: Manchmal können die Einstellungen des Betriebssystems den Schreibschutz aktivieren.

Mögliche Lösungen

1. Überprüfen des Schreibschutzschalters:

Wenn vorhanden, stelle sicher, dass der Schalter auf "entsperrt" steht.
2. Formatieren des USB-Sticks:

Versuche, den USB-Stick zu formatieren. Dies kann jedoch alle Daten löschen.
Gehe zu "Dieser PC", klicke mit der rechten Maustaste auf den USB-Stick und wähle "Formatieren".
3. Überprüfung auf Viren:

Scanne den USB-Stick mit einem aktualisierten Antivirenprogramm.
4. Verwendung von Diskpart (Windows):

Öffne die Eingabeaufforderung als Administrator.
Gib diskpart ein, dann list disk , um deine Laufwerke anzuzeigen.
Wähle den USB-Stick mit select disk X (ersetze X durch die Nummer deines USB-Sticks).
Gib attributes disk clear readonly ein, um den Schreibschutz zu entfernen.
Test an einem anderen Computer:

Schließe den USB-Stick an einen anderen Computer an, um zu prüfen, ob das Problem weiterhin besteht.

Wenn die oben genannten Schritte das Problem nicht lösen, könnte es sein, dass der USB-Stick defekt ist. In diesem Fall wäre es ratsam, den Kundendienst von Kingston zu kontaktieren.
Andreas:
1. ist nicht vorhanden. 2. geht nicht weil schreibgeschützt (nicht mal ein secure-erase funktioniert). 3. es gibt auf meinem System keine Schädlinge und es sind auch keine anderen Laufwere betroffen. 4. ich nutze Linux
Aria:
Danke für die zusätzlichen Informationen! Hier sind einige spezifische Schritte, die du unter Linux ausprobieren kannst, um den Schreibschutz auf deiner Kingston XS 1000 zu umgehen:

Mögliche Lösungen für Linux

1. Überprüfen des Schreibschutzstatus:

Öffne ein Terminal und führe den folgenden Befehl aus, um den Status des Laufwerks zu überprüfen:

lsblk -o NAME,SIZE,RO

Achte darauf, ob das Laufwerk in der Spalte "RO" (Read-Only) als "1" angezeigt wird.
Versuch, den Schreibschutz aufzuheben:

2. Du kannst die hdparm -Befehlszeile verwenden, um den Schreibschutz zu überprüfen oder zu ändern:

sudo hdparm -r0 /dev/sdX

Ersetze /dev/sdX durch den entsprechenden Gerätenamen deiner SSD.
Verwendung von parted :

3. Starte parted im Terminal:

sudo parted /dev/sdX

Gib dann den Befehl print ein, um die Partitionstabelle anzuzeigen.
Überprüfe die Statusinformationen und versuche, den Schreibschutz zu entfernen.
Datenrettung und Neuformatierung:

4. Falls die oben genannten Schritte nicht funktionieren, könntest du versuchen, mit ddrescue oder testdisk eine Datenrettung durchzuführen, bevor du einen letzten Versuch unternimmst, den USB-Stick zu formatieren:

sudo ddrescue /dev/sdX /path/to/image.img /path/to/logfile.log

Danach kannst du mit gparted oder mkfs eine neue Partition erstellen.
Hardware-Defekt prüfen:

5. Wenn alle oben genannten Schritte nicht funktionieren, könnte es ein Hardware-Defekt sein. In diesem Fall ist es ratsam, Kontakt mit dem Kingston-Support aufzunehmen.

Bitte führe die Befehle vorsichtig aus, insbesondere wenn du mit dd oder parted arbeitest, da falsche Eingaben zu Datenverlust führen können.
Andreas:
1. Zeigt beim betreffenden Laufwerk und sämtlichen Partitionen RO=1 an.
2. (sudo hdparm -r0 /dev/sdc*) will beim Laufwerk und den Partitionen RO=0 setzen, es bleibt aber alles auf RO=1.
3. zeigt eine Warnung, dass das Laufwerk nicht zum schreiben geöffnet werden kann und deshalb nur lesbar geöffnet wird. Es gibt keine Option, den Schreibschutz zu ändern.
4. ist egal, da keine Daten gerettet werden müssen und die Formatierung funktioniert nicht, da readonly.
scheint am wahrscheinlichsten, da das Laufwerk neu ist und es passierte, während ich erstmals meine Daten drauf kopiert habe: Nach ca. 500 GB.
Dann fing es an sich im Kreis zu drehen: neue Firmware flashen (die es nicht gibt und wegen Schreibschutz vermutlich sowieso nicht möglich wäre), oder das Laufwerk auseinander bauen (das winzige Ding, was sich vermutlich nicht mal zerstörungsfrei öffene lässt) und versuchen es selbst zu reparieren (klar), usw.

Heute bin ich nicht dazu gekommen Reichelt anzurufen, aber da erst letzten Do. geliefert, eilt es ja noch nicht.

Zumindest bin ich jetzt sicher, dass es nichts mehr gibt was ich vielleicht testen soll, das ich nicht schon getestet habe, oder fundiert ausschließen kann. :)
 
Ich bin heute erst dazu gekommen bei Reichelt anzurufen:

Bzgl. dass alle meine Daten drauf sind (Bankverbindungen, Versicherungen, Passwörter für alle meine Konten wie eBay, PayPal, usw.) und ich sie nicht mehr löschen kann (auch ein Secure-Erase funktioniert nicht), gab es nur zwei Möglichkeiten:

1. ich schicke sie trotzdem ein: Sowohl Reichelt als auch der Hersteller sind bei Datenträgern dazu verpflichtet das vertraulich zu behandeln.

2. ich behalte sie und bleibe auf den Kosten sitzen (was ich mir nicht leisten kann)

Da ich die Home-Partition verschlüsselt erstellt hatte (davon hatte ich gegenüber Reichelt nichts gesagt) und niemand ohne unverhältnismäßig großen Aufwand an die Daten kommen kann, habe ich mich natürlich für 1. entschieden.

Dass ich die SSD physisch zerstöre (mit dem Bohrer durch den Speicherchip) ist keine Option, da es dann nicht mehr als Garantiefall anerkannt wird.

Fazit:

Nutzt Verschlüsselung, wo immer es sinnvoll ist. - Man weiß nie was vielleicht passiert.
 
Zurück
Oben