USB HDD lässt sich nicht mehr einhängen

[Maxodermoritz]

Hallo,

ich bekomme meine 320GB HDD nicht mehr über USB eingehängt.
Unter KDE öffnet sich nach dem Einstecken der Platte der Dialog zum Einhängen und im Anschluss dann die Aufforderung zur Passworteingabe (LUKS verschlüsselt). Danach verschwindet das Fenster wieder und ploppt erneut auf. Das Ganze geht dann immer so weiter. Selbst, wenn ich es schaffe, das Passwort einzugeben.

Hier mal die Logmeldung nach dem Einstecken der Platte:

Code: Alles auswählen

Feb 26 18:34:39 debian kernel: [ 3594.495458] usb 7-1: new high-speed USB device number 8 using ehci-pci
Feb 26 18:34:39 debian kernel: [ 3594.653742] usb 7-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
Feb 26 18:34:39 debian kernel: [ 3594.653762] usb 7-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
Feb 26 18:34:39 debian kernel: [ 3594.653769] usb 7-1: Product: USB 3.0 Destop HD EP0 Product string
Feb 26 18:34:39 debian kernel: [ 3594.653775] usb 7-1: Manufacturer: ASMT
Feb 26 18:34:39 debian kernel: [ 3594.653780] usb 7-1: SerialNumber: 0000000000A3
Feb 26 18:34:39 debian kernel: [ 3594.656380] scsi host4: uas
Feb 26 18:34:39 debian kernel: [ 3594.658252] scsi 4:0:0:0: Direct-Access     ASMT     USB 3.0 Destop H 0    PQ: 0 ANSI: 6
Feb 26 18:34:39 debian kernel: [ 3594.661042] sd 4:0:0:0: Attached scsi generic sg2 type 0
Feb 26 18:34:39 debian kernel: [ 3594.661857] sd 4:0:0:0: [sdb] Spinning up disk...
Feb 26 18:34:39 debian mtp-probe: checking bus 7, device 8: "/sys/devices/pci0000:00/0000:00:1a.7/usb7/7-1"
Feb 26 18:34:39 debian mtp-probe: bus: 7, device: 8 was not an MTP device
Feb 26 18:34:39 debian mtp-probe: checking bus 7, device 8: "/sys/devices/pci0000:00/0000:00:1a.7/usb7/7-1"
Feb 26 18:34:39 debian mtp-probe: bus: 7, device: 8 was not an MTP device
Feb 26 18:34:42 debian kernel: [ 3595.683448] ...ready
Feb 26 18:34:42 debian kernel: [ 3597.805646] sd 4:0:0:0: [sdb] 625142448 512-byte logical blocks: (320 GB/298 GiB)
Feb 26 18:34:42 debian kernel: [ 3597.806109] sd 4:0:0:0: [sdb] Write Protect is off
Feb 26 18:34:42 debian kernel: [ 3597.806859] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Feb 26 18:34:42 debian kernel: [ 3597.810151] sd 4:0:0:0: [sdb] Optimal transfer size 33553920 bytes
Feb 26 18:34:42 debian kernel: [ 3597.856972] sd 4:0:0:0: [sdb] Attached SCSI disk
Feb 26 18:35:13 debian kernel: [ 3629.198238] usb 7-1: USB disconnect, device number 8
Feb 26 18:35:13 debian kernel: [ 3629.219826] sd 4:0:0:0: [sdb] Synchronizing SCSI cache
Feb 26 18:35:14 debian kernel: [ 3629.471103] sd 4:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Feb 26 18:35:15 debian kernel: [ 3631.199079] usb 7-1: new high-speed USB device number 9 using ehci-pci
Feb 26 18:35:16 debian kernel: [ 3631.361425] usb 7-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
Feb 26 18:35:16 debian kernel: [ 3631.361443] usb 7-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
Feb 26 18:35:16 debian kernel: [ 3631.361451] usb 7-1: Product: USB 3.0 Destop HD EP0 Product string
Feb 26 18:35:16 debian kernel: [ 3631.361457] usb 7-1: Manufacturer: ASMT
Feb 26 18:35:16 debian kernel: [ 3631.361462] usb 7-1: SerialNumber: 0000000000A3
Feb 26 18:35:16 debian kernel: [ 3631.368147] scsi host4: uas
Feb 26 18:35:16 debian kernel: [ 3631.373057] scsi 4:0:0:0: Direct-Access     ASMT     USB 3.0 Destop H 0    PQ: 0 ANSI: 6
Feb 26 18:35:16 debian mtp-probe: checking bus 7, device 9: "/sys/devices/pci0000:00/0000:00:1a.7/usb7/7-1"
Feb 26 18:35:16 debian mtp-probe: bus: 7, device: 9 was not an MTP device
Feb 26 18:35:16 debian kernel: [ 3631.375545] scsi 4:0:0:0: Attached scsi generic sg2 type 0
Feb 26 18:35:16 debian mtp-probe: checking bus 7, device 9: "/sys/devices/pci0000:00/0000:00:1a.7/usb7/7-1"
Feb 26 18:35:16 debian mtp-probe: bus: 7, device: 9 was not an MTP device
Feb 26 18:35:16 debian kernel: [ 3631.402415] sd 4:0:0:0: [sdb] 625142448 512-byte logical blocks: (320 GB/298 GiB)
Feb 26 18:35:16 debian kernel: [ 3631.402791] sd 4:0:0:0: [sdb] Write Protect is off
Feb 26 18:35:16 debian kernel: [ 3631.404468] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Feb 26 18:35:16 debian kernel: [ 3631.405105] sd 4:0:0:0: [sdb] Optimal transfer size 33553920 bytes
Feb 26 18:35:16 debian kernel: [ 3631.505169] sd 4:0:0:0: [sdb] Attached SCSI disk
Feb 26 18:35:18 debian kernel: [ 3634.221267] usb 7-1: USB disconnect, device number 9
Feb 26 18:35:18 debian kernel: [ 3634.248071] sd 4:0:0:0: [sdb] Synchronizing SCSI cache
Feb 26 18:35:19 debian kernel: [ 3634.487061] sd 4:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

Ich benutze einen stromlosen USB / SATA Adapter an verschiedenen USB 2.0 Anschlüssen an zwei verschiedenen Rechnern mit gleichem System.
Bisher ging das immer, nur hatte ich in der Vergangenheit öfter auch mal Probleme mit verschlüsselten USB-Sticks.
Unverschlüsselte USB-Speicher haben bislang keine Probleme gemacht.

Hat jemand eine Idee, wie ich verhindern kann, dass immer wieder ein Einhängeversuch gemacht wird, sodass ich vielleicht mal einen Rettungsversuch der Platte starten oder eine Sicherungskopie anlegen kann?
Gibt es vielleicht noch andere Möglichkeiten, die Platte wieder ordentlich einzuhängen?

Grüße

[hikaru]

Ich benutze einen Stromlosen USB / SATA Adapter an verschiedenen USB 2.0 Anschlüssen an zwei verschiedenen Rechnern mit gleichem System.

Das ist eine eher ungünstige Kombination, da USB 2.0 innerhalb der Spezifikation nicht genug Strom zur Verfügung stellt um eine 2,5"-HDD zu betreiben. Meist funktioniert es trotzdem, weil die meisten Rechner mehr Strom zur Verfügung stellen als spezifiziert. Aber gerade in einer Problemsituation ist das ein weiterer Stolperstein.
Kannst du die HDD direkt per SATA oder wenigstens über USB 3.0 anschließen?

Was KDE beim Mountversuch macht weiß ich nicht. Angenommen die Stromversorgung wäre gesichert, versuch mal, die HDD zu Fuß im Terminal zu mounten!

[fischig]

Ich bin ja nur so'n dummer Anwender. aber mir scheint, es ist keine Partitionierung erkennbar. Ist doch eher unüblich oder Hinweis auf kaputt - richtig? Vielleicht hilft's ja weiter. Wenn nicht, vergesst es einfach.

[Maxodermoritz]

@hikaru
Das mit dem Mounten zu Fuß würde ich gern vorerst noch lassen, denn ich hatte damit bei vorherigen Versuchen bei meinen USB-Sticks auch kein Glück.
Hier bestand aber nicht das Problem mit dem ständigen Aufploppen des Fensters für das Einhängen.
Ich wurde lediglich einmal aufgefordert, den Datenträger einzuhängen und wenn ich das nicht tat, verschwand das Fenster und weitere Einhängeversuche unterblieben.
Dann konnte ich den Stick reparieren und alles war (erst mal) wieder gut. Später klappte das dann irgendwann nicht mehr und 2 Sticks waren hinüber. Ich nahm an, dass das was mit der Marke (Intenso) zu tun hat, aber gehe nun eher davon aus, dass es mit der Verschlüsselung zusammenhängt.

Ich habe die Platte aber schon an den internen SATA-Anschluss gesteckt und den Rechner mit einem Live-Linux gebootet, um zu gucken, ob es am geringen Strom liegt/lag. Aber auch hier ließ sich die Platte nicht einhängen. Ich wollte dann erst mal nicht weiter rumexperimentieren (auf Grund meiner bereits gesammelten Erfahrungen) und habe die Platte erst mal wieder ausgebaut. Die Logmeldungen hatte ich dabei ganz vergessen anzugucken.

@fischig
Ich kann in den Logmeldungen keinen Hinweis darauf finden, dass die Partitionstabelle einen Knick hat.
Woran kannst Du das sehen? Kannst Du mal bitte den entsprechenden Abschnitt posten?

[fischig]

Wenn ich nicht wieder mal Tomaten auf den Augen habe: Ich seh' immer nur sdb, nie sdb1, sdb2, etc. Das wären dann Partitionen, von denen mindestens eine vorhanden sein sollte - denk' ich mal.

[Maxodermoritz]

Aber Partitionstabellen lassen sich manchmal reparieren. Das würde ich dann ggf. mal gern versuchen.
Ist nur sdb1 drauf (bzw. eine prim. Partition).

[fischig]

Könnte via testdisk funktionieren - wenn du alle Vorschläge hikarus erfolglos durch hast. Ist aber nicht ohne, insbesondere, wenn man gewohnt ist, dass solche grundlegenden Dinge wie Mounten von rundum-sorglos-GUIs wie KDE ohne eigenes Zutun erledigt werden! Und deswegen sollten da kompetentere Leute als ich VOR dem Versuch noch Detaillierteres zu schreiben.

[Maxodermoritz]

@fischig

Danke!
Mit testdisk habe ich tatsächlich keine Erfahrungen, aber vielleicht kann es helfen.
Das mit dem KDE-Fenster ist für mich nur ein erster Indikator, dass da was mit dem Einhängen nicht klappt. Wichtiger sind für mich die Logmeldungen, denen ich aber auch nicht viel Aufschlussreiches entnehmen kann, außer, dass, wie Du schon schriebst, nur die Platte zu sehen ist, aber keine Partition(en).
Ich werde es also später mit dem manuellen Einhängen ggf. noch mal versuchen. Momentan habe ich nur die Sorge, dass die Platte dabei zu sehr gestresst wird.

Ich habe inzwischen noch mal eine andere (unverschlüsselte) baugleiche Platte mit dem Adapter an den Rechner gehängt, um nach bestimmten Daten zu suchen.
Zu meinem Erstaunen passierte hier genau dasselbe und ein Einhängen war nicht möglich.
Nachdem ich die HDD schnell wieder vom Adapter abgenommen habe, habe ich sie mal in den passenden Rechner gesteckt und die beiden Systeme, welche sich darauf befinden, gebootet. Das ging ohne Probleme. Die Platte scheint heil zu sein, ließ sich aber mit dem Adapter nicht einhängen. Demzufolge kann ich annehmen, dass vielleicht mein (neuer) Adapter auch eine Fehlerquelle sein könnte (Ich hatte mit solchen Teilen noch nie Glück). Da sich meine Problemplatte aber auch über den internen SATA-Anschluss nicht (wie gewohnt) einhängen lässt, gehe ich davon aus, dass sie nicht mehr in Ordnung ist und vielleicht den eventuell defekten Adapter nicht vertragen hat.
Die andere Platte, welche sich noch booten ließ, hatte ich wohl schnell genug wieder abgenommen.

Nun gucke ich erst mal, dass ich einen neuen Adapter bekomme.
Falls jemand einen Tipp hat, welches Modell von ordentlicher Qualität ist, würde ich mich über einen Hinweis freuen.

[Maxodermoritz]

Die Platte geht wieder.
Es lag tatsächlich an meinem neuen Adapter.

Die Frage, warum meine verschlüsselten Sticks Probleme machen und alle nacheinander kaputtgehen, stelle ich mir aber immer noch und finde so richtig keine Antwort.
Wenn da noch jemand eine Idee hat, bitte mal schreiben.
Ansonsten erst mal danke an alle, die geholfen haben!

Grüße

[hikaru]

Die Frage, warum meine verschlüsselten Sticks Probleme machen und alle nacheinander kaputtgehen, stelle ich mir aber immer noch und finde so richtig keine Antwort.
Wenn da noch jemand eine Idee hat, bitte mal schreiben.

USB-Sticks sind Flashspeicher mit im Vergleich zu SSDs meist schlechtem, oder gar ganz ohne Wear-Levelling. Jeder Schreibvorgang auf eine Flashzelle bechädigt diese. Moderne Dateisysteme berücksichtigen das und organisieren die Schreibzugriffe so, das möglichst wenige Schreibvorgänge durchgeführt werden.
Wenn du nun eine Verschlüsselung zwischen Dateisystem und Flash-Controller hängst, dann machst du damit die "Intelligenz" des Dateisystems zunichte und die Schreiblast steigt enorm.

Hinzu kommt, dass gerade billige USB-Sticks ihre werbewirksamen Übertragungsraten dadurch erreichen, dass auf Flash-Controller-Ebene RAID-Techniken eingesetzt werden, welche abermals die Schreiblast erhöhen.
Wenn du für Verschlüsselung gut geeignete Sticks suchst, dann musst du Benchmarks wälzen und dabei die random-Write-Performance vergleichen! Wenn nichts näher angegeben wird, dann bezieht sich die Schreibgeschwindigkeit für gewöhnlich auf die sequenzielle Schreibleistung, was für dich uninteresant ist.

Falls die Baugröße nicht kritisch ist, wäre es für diesen Zweck sinnvoller, eine richtige SSD in einem externen Gehäuse zu verwenden. Wenn du eine fertige externe SSD nimmst, hast du aber wie bei USB-Sticks oft das Problem, dass es schwer ist herauszufinden, welcher Flash-Typ da verbaut ist. Wenn du sicher gehen willst kaufst du eine interne SSD mit guten Benchmarks (ideal wäre SLC; MLC ist besser als TLC; QLC besser meiden) und steckst sie selbst in ein externes Gehäuse.

[DeletedUserReAsG]

Wenn du nun eine Verschlüsselung zwischen Dateisystem und Flash-Controller hängst, dann machst du damit die "Intelligenz" des Dateisystems zunichte und die Schreiblast steigt enorm.

Eigentlich™ nicht – zumindest dm_crypt ist transparent: ein geschriebener Block im FS ist ein geschriebener Block auf dem Device (wenn auch mit anderem Inhalt).

[hikaru]

Das wäre in der Tat intelligent! Hast du dazu eine Quelle?

[DeletedUserReAsG]

Hast du dazu eine Quelle?

Eigene Beobachtung. Ansonsten mal in der dm_crypt-Doku schauen, da sollte auch ein Schema zu finden sein.

Das ist auch der Grund, warum sich HDD-Defekte in Form von kaputten Blöcken bei verschlüsselten Devices nicht anders äußern, als bei unverschlüsselten Devices (vorausgesetzt, der Fehler ist nicht ausgerechnet im LUKS-Header).

[MSfree]

Eigentlich™ nicht – zumindest dm_crypt ist transparent: ein geschriebener Block im FS ist ein geschriebener Block auf dem Device (wenn auch mit anderem Inhalt).

Das Problem eines verschlüsselten Dateisystems ist, daß auch die nicht benutzten Speicherbereiche beim Einrichten mit binärem Salat beschrieben wird. Damit hebelt man das Wearlevelling der SSD aber aus, bis auf ein paar Reserveblöcke sind ja alle Blöcke aus Sicht des Waerlevellings belegt. Die Logik, die das Waerlevelling verwaltet, hat dann keine Chance, Daten auf freie, unbelegte Blöcke zu schreiben.

[DeletedUserReAsG]

Damit hebelt man das Wearlevelling der SSD aber aus, bis auf ein paar Reserveblöcke sind ja alle Blöcke aus Sicht des Waerlevellings belegt. Die Logik, die das Waerlevelling verwaltet, hat dann keine Chance, Daten auf freie, unbelegte Blöcke zu schreiben.

Das gleiche Problem tritt aber auch ohne Verschlüsslung auf: die Dateien im FS werden nur entlinkt, die Daten bleiben liegen, bis sie irgendwann überschrieben werden. Für den Controller des SSD ist nicht ersichtlich, was davon weg kann – der ist darauf angewiesen, das mitgeteilt zu bekommen. Etwa via trim – und das geht dann wieder genauso mit dm_crypt-Layer dazwischen.

Wenn es anders sein soll, müsste der Controller das Dateisystem lesen können, um zu wissen, welche Blöcke zu einer Datei gehören, und welche nicht mehr.

Edit: „beim Einrichten“ nicht berücksichtigt, daher der Nachtrag dazu: einerseits ist das nicht obligatorisch, andererseits wird der gleiche Zustand auch im normalen Betrieb und einem gewissen Füllgrad recht bald erreicht.

[MSfree]

Das gleiche Problem tritt aber auch ohne Verschlüsslung auf: die Dateien im FS werden nur entlinkt, die Daten bleiben liegen

Genau deswegen wurde für SSDs TRIM eingeführt. Dabei sorgt der Kernel nicht nur dafür, daß die Daten "entlinkt" werden sondern gibt der SSD die Information, daß der Block nicht weiter benötigt wird. Die SSD nullt den Block daraufhin und sortiert ihn inklusive der bisherigen Anzahl Löschvorgänge in die Liste der vorbereiteten Datenblöcke ein.

Bei verschlüsseltem Dateisystemen will man vermeiden, daß man anhand der genullten Blöcke Rückschlüsse ziehen kann, wo die eigentlichen Daten zu finden sind, so daß man hier quasi gezwungen ist, TRIM nicht zu verwenden.

[DeletedUserReAsG]

Bei verschlüsseltem Dateisystemen will man vermeiden, daß man anhand der genullten Blöcke Rückschlüsse ziehen kann, wo die eigentlichen Daten zu finden sind, so daß man hier quasi gezwungen ist, TRIM nicht zu verwenden.

Wenn man es vermeiden möchte, könnte man sich gezwungen fühlen. Objektiv ist es aber nicht zwingend, sondern es liegt an jedem selbst, diese Entscheidung für sich zu treffen.

[Maxodermoritz]

Danke Euch für die Informationen! Auch wenn ich nicht alles verstanden habe, aber bei diesen Sticks kann ich nicht länger bleiben bzw. werde dann mal gucken, dass ich meine Daten vielleicht auf hochwertigeren Sticks oder Platten unterbringe.

Grüße