camcontrol gibt "ATA SECURITY_ERASE_UNIT via pass_16 failed" zurück

bsd4me

Well-Known Member
Hallo,

ich habe eine WD archive Disk, die würde ich gerne zum Backup nutzen. Ist eine SMR disk. Das ging zu Anfang auch ganz gut, nur nach etwa 1 Stunde brach der Datentransfer total ein... Auch ein reformat ist sehr langsam.

Dann habe ich mit camcontrol mal experementiert - bin allerdings nicht firm darin:

# camcontrol security da4
pass7: <ST6000AS0002-1N917X AR15> ACS-2 ATA SATA 3.x device
pass7: 400.000MB/s transfers

Security Option Value
supported yes
enabled yes
drive locked no
security config frozen no
count expired no
security level high
enhanced erase supported yes
erase time > 508 min
enhanced erase time > 508 min
master password rev fffb


und

# camcontrol security da4 -U user -s secret -h secret -T 60
pass7: <ST6000AS0002-1N917X AR15> ACS-2 ATA SATA 3.x device
pass7: 400.000MB/s transfers

You are about to ERASE ALL DATA from the following device:
pass7,da4: <ST6000AS0002-1N917X AR15> ACS-2 ATA SATA 3.x device

Are you SURE you want to ERASE ALL DATA? (yes/no) yes
Issuing SECURITY_SET_PASSWORD password='secret', user='user', mode='high'
Issuing SECURITY_ERASE_PREPARE
Issuing SECURITY_ERASE_UNIT password='secret', user='user'

camcontrol: ATA SECURITY_ERASE_UNIT via pass_16 failed

egal, mit welchen Parametern ich es versuche, es bleibt immer bei dem "SECURITY_ERASE_UNIT via pass_16 failed". Im Internet finde ich dazu ncihts. Vielleicht hat jemand von Euch eine Idee? Das würe spzitze!!!

VG Norbert
 
Vielleicht mal mit einem Linux-Bootmedium (USB-Memorystick) und der nachfolgenden Anleitung versuchen. Oder die hdparm-Befehle durch die entsprechenden camcontrol-Äquivalenten ersetzen:

Anleitung Secure Erase auf Intel SSD
=======================================

1.) Im BIOS das Festplattenverschlüsselungs-
passwort entfernen (HP BIOS -> DriveLock).

2.) Rechner mit dem Rescue System von der SLED-
Installations-DVD starten.

3.) # hdparm -I /dev/sda

-> Master password
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase

Falls die Zeile "not frozen" fehlt und "frozen" in
der entsprechenden Zeile steht, muss die SSD aufgeweckt
werden:

# echo -n mem > /sys/power/state
Danach den Laptop aus dem Standby-Modus wecken.
Einfach mit der Power-Taste den Laptop wecken.

4.) # hdparm --user-master m --security-set-pass NULL /dev/sda
-> Das neue, leere Master-Passwort der Festplattenverschlüsselung wird
gesetzt.

5.) # hdparm --user-master u --security-set-pass NULL /dev/sda
-> Das neue, leere Benutzer/User-Passwort der Festplattenverschlüsselung
wird gesetzt.

6.) # hdparm --security-erase NULL /dev/sda

7.) # hdparm --security-erase-enhanced NULL /dev/sda
-> Falls Schritt 7 nicht funktioniert, müssen die Schritte 4 bis 5
wiederholt werden!

8.) # poweroff
-> Rechner herunterfahren

Für weitere Informationen siehe das exzellente ArchLinux-Wiki:
 
Also sortieren wir das mal. :)

Du hast die 6TB-Variante, anhand der Modellnummer:

1.) Was genau hattest du mit camcontrol vor?
2.) Ein security erase ist gedacht, wenn die Platte den Besitzer wechselt und man sie blank übergeben will. Das gibt es auch an sich, weil es oft viel schneller als einmal low level/dd drüberbügeln durchläuft. 6TB dauern regulär eine Ewigkeit, ich würde jetzt grob 48h schätzen.
3.) Laut diesem spec-paper ist "Seagate Instant Secure Erase" optional, es gibt also jeweils zwei Varianten. ST6000AS0002 vs. ST6000AS0012, du hast dann das Modell ohne.
4.) Ich weiß nicht, ob dieses "Seagate Instant Secure Erase" Seagatescher Eigenbau ist oder nur blödes Marketingbuzz für das reguläre standard security erase
5.) Anhand der Übertragungsrate 400.000MB/s lese ich heraus, dass das USB3 ist und es dürfte daher eine externe Platte sein. Laut specs kann die Platte am Anschluss nämlich 600.000MB/s (SATA Transfer Rates Supported (Gb/s) -> 6.0)
Daraus ergibt sich das womöglich weitere Problem, dass USB-Controller Dinge nicht durchreichen/wegschlucken/vorlügen, wie z.B. die ganze Palette an ATA-Zeugs. Das heißt womöglich, selbst wenn du in diesem Gehäuse das Modell ST6000AS0012 hättest, "Seagate Instant Secure Erase" standardkonform wäre, dass dir der USB-Controller einen Strich durch die Rechnung macht.
6.) Nochmal zu Punkt 1. Was geht denn jetzt genau nicht? Da das eine SMR-Platte ist, ist die einbrechende Schreibrate der zu erwartende Effekt. Das ändert man auch nicht mit einer Formatierung.
Wenn die Platte gar nicht mehr reagiert, müsste man anders anhebeln. Aber ich glaube, das war nicht das Thema. ;)
 
Hi @mr44er - danke für den Beitrag. Eigentlich geht es um Punkt 6 - ich möchte, dass die Platte wieder einigermassen schnell schreibt. Wenn das nicht mehr geht - landet auf den Müll. Mit camcontrol hatte ich gelsen, man könne das wiedeherstellen - daher mein Ausflug in diese Richtung... Viele Grüße, Norbert
 
Wenn das nicht mehr geht - landet auf den Müll
Halte ich für übertrieben, sie ist ja nicht defekt. ;)

Die SMR-Technik ist halt gedacht für überwiegend Draufschreiben, immer nach vorne, niemals löschen. Das geht zwar, aber da durch die Überlappung dann viel umgeschichtet werden muss, bricht eben die Schreibrate ein.
 
Ja, Du hast recht, sie ist zwar Jahre alt - aber kaum genutzt... Letztens erst, als ich etwa 300GB per rsync auf die Platte schreiben (backupen) wollte, und das ganze dann nach etwa 1 Stunde drastisch einbrach. in dem Backup sind Dateien von einigen GB bis einigen KB an Groesse. aber nix exotisches... Und zum Backup hatte ich sie extra damals gekauft.
 
Technisch wäre die beste Lösung, die Platte in einen Rechner einzubauen, damit sie direkt an einem SATA-Port hängt. Damit umgehst du den Mist mit USB-Controller und hast maximale Geschwindigkeit anliegen, verlierst aber eben die Portabilität.

Interne Platte als Backup nutzen ist halt auch kein Kracher im Fall von Diebstahl/Blitz/Brand, aber eben besser als gar kein Backup oder drölfzig Stunden aufs Backup warten, wenn man sie am USB3 anstöpselt.
 
Eigentlich geht es um Punkt 6 - ich möchte, dass die Platte wieder einigermassen schnell schreibt.
Ich empfehle ein trim -f /dev/$device unter FreeBSD oder `blkdiscard -f /dev/$device unter Linux. Das schickt ein TRIM auf alle Blöcke der ganzen SSD oder der angegeben Partition, wonach die Blöcke aus Sicht des Controllers wieder unbelegt sind. Es benötigt weniger Firmware-Kooperation als ein Secure Erase und hat daher weniger Fehlerpotential. Je nach SSD kehrt der Befehl sofort oder erst nach einigen Minuten zurück. Es ist dabei immer eine gute Idee, die SSD hinterher noch zehn Minuten oder so in Ruhe eingesteckt zu lassen, damit der Controller sich reorganisieren kann.

Aber auch das wird eher nicht durch eine USB<->S-ATA-Brücke funktionieren.

Nachtrag: Auch wenn ich aus Reflex SSD geschrieben habe, unterstützen auch viele moderne HDDs TRIM. Allerdings nicht alle.
 
5.) Anhand der Übertragungsrate 400.000MB/s lese ich heraus, dass das USB3 ist und es dürfte daher eine externe Platte sein. Laut specs kann die Platte am Anschluss nämlich 600.000MB/s (SATA Transfer Rates Supported (Gb/s) -> 6.0)
Daraus ergibt sich das womöglich weitere Problem, dass USB-Controller Dinge nicht durchreichen/wegschlucken/vorlügen, wie z.B. die ganze Palette an ATA-Zeugs. Das heißt womöglich, selbst wenn du in diesem Gehäuse das Modell ST6000AS0012 hättest, "Seagate Instant Secure Erase" standardkonform wäre, dass dir der USB-Controller einen Strich durch die Rechnung macht.

Für höchste Performance muss ein per USB-Kabel angeschlossener Datenträger mit UAS respektive UASP vom Betriebssystem über das USB-Kabel angesprochen werden. Und eben dieser UAS-Modus wird von FreeBSD offenbar bis heute nicht unterstützt:





UAS/UASP wird ab USB 2.0 von moderner Hardware unterstützt.


Auch per USB-Kabel am Computer angeschlossene Datenträger unterstützen den TRIM-Befehl. Da UAS/UASP auf SCSI basiert, darf das Betriebssystem beim Einsatz von TRIM auf USB-Medienträgern keinen ATA TRIM-Befehl verwenden, sondern muss einen SCSI UNMAP-Befehl versenden.


Unter Linux muss ich für den TRIM-Befehl auf der per USB-Kabel im UAS-Modus angeschlossenen SSD Samsung Portable T5 wie folgt vorgehen:

# echo "unmap" > /sys/block/sdb/device/scsi_disk/*/provisioning_mode
# fstrim -v /usr/lib/microcode/backup

Auch für das Sichere Datenlöschen (Secure Erase) sieht SCSI (und somit UAS/UASP) andere Befehle vor (SANITIZE statt SECURE ERASE):

Das Sicheres Datenlöschen (Secure Erase) der per USB-Kabel im UAS-Modus angeschlossenen SSD Samsung Portable T5 muss unter Linux mit dem Befehl:

# blkdiscard --secure /dev/sdc

erfolgen. Gemäss der oben stehenden Fehlermeldung sieht es danach aus, als würde camcontrol den SCSI-Befehl "SANITIZE" nicht unterstützen.

Verschlüsselte Datenträger, wie "Seagate Instant Secure Erase", werden beim Erhalt des Befehls für das Sichere Datenlöschen (Secure Erase) im Krypto-Chip das bestehende, alte Schlüsselmaterial (AES128/AES256) durch neues Schlüsselmaterial ersetzen. Solange die Verschlüsselung mit AES unknackbar ist, ist diese Datenlöschung sicher, schnell und unwiderruflich. Der Krypto-Chip befindet sich auf dem Datenträger.
 
Super Dank für die vielen Beiträge :-) Aber was mich wirklich interessiert, ist die Übertragungsrate, die sehr massiv gesunken ist auf der 6TB Seagate Archive SMR disk. Das mit dem (secure) erase hatte ich irgendwo gelesen, dass es helfen sollte. Das war eigentlich alles. Und ob ich nun mit 400 oder 600 MB/sec übertrage, ist zweitrangig, dass schafft die Platte ja sowieso nicht... Letztendlich speichere ich per geli oder pefs die Daten, damit ist mir das "verschlüsselt" genug. Ich habe ja keine hochrangig privaten Daten zu sichern. Also nochmals danke für alle Kommentare. Sie sind auf jeden Fall hilfreich :-) VG Norbert
 
Die ST6000AS0002 ist eine SMR-Platte der ersten Generation. Die sind einfach - sorry - scheiße. Neuere Modelle verhalten sich wesentlich besser. Diese erste Generation hatte einen kleinen Bereich mit klassischem PMR, sozusagen als Cache. Der Rest ist SMR, mit festen Spurlängen. Wie lang die Spuren sind, hat Seagate meines Wissens nie öffentlich kommuniziert. Ich würde mit meiner Erfahrung mit den 2,5"-Varianten auf mindestens 256 Megabyte tippen. Das Problem dabei ist, dass die Spuren als Ganzes neugeschrieben werden müssen. Ändert sich nur ein Bit, müssen also 256 Megabyte neu geschrieben werden. Das ist Write Amplification extrem. Schnell sind sie nur, solange in den PMR-Cache geschrieben wird und sie Platte hinterher Zeit bekommt sich zu reorganisieren. Sonst rattert, rattert und rattert sie und es kommt doch kein Durchsatz.

Würde sie TRIM können, wüsste der Controller welche Blöcke tatsächlich belegt sind und kann sich entsprechend organisieren. Das ist dann, solange genügend freier Speicher vorhanden ist, durchaus schnell. Vor allem, wenn die Spuren noch eine variable Länge haben. Ohne TRIM sind aber irgendwann aus Sicht des Controller alle Blöcke belegt und er muss zwingend bei jeder Änderung komplette Spuren neuschreiben. Secure Erase würde vorübergehend helfen, da es alle Blöcke als frei markiert. Aber irgendwann sind wieder alle Blöcke belegt und die Katastrophe geht von vorne los.

Die pragmatische Lösung ist, die Platte auszutauschen und Fall erledigt. Alternativ hilft es, große Datenmengen - mindestens 256 Megabyte am Stück - zu schreiben. Und auf keinen Fall ZFS zu nehmen, denn das ist dank Copy on Write und dem damit verbundenen Vermeiden Blöcke zu überschrieben tödlich. Dafür braucht man aber ein entsprechendes Backupprogramm. Meiner Erfahrung nach funktioniert Restic mit https://github.com/restic/restic/pull/3731 gepatcht und anschließend --min-packsize 256M auf UFS durchaus gut, ist aber nicht sonderlich Speicherplatzeffient. Gerade in inkrementellen Läufen, die nur wenig Änderungen haben.
 
Vielen dank @Yamagi ! Für externe Platten nehme ich immer UFS als Dateisystem :-) Für mich ist damit klar, dass diese Platte ungeeignet für Backups ist, und damit generell ungeeignet, um damit zu arbeiten - ich werde sie auf jeden Fall "entsorgen"... VG Norbert
 
du solltest vielleicht doch noch andere Programme als rsync probieren.
rsync ist zwar mein Liebling seit vielen Jahren, aber gerade unter FreeBSD sehe ich auch, dass es mitunter schon sehr lange braucht, um seine Dateilisten zu erstellen. Es gibt da in den Optionen einige Dinge, die dann Verbesserungen bringen können, aber nicht wirklich immer gut funktionieren (wie etwa kleine Dateien auslassen oder Prüfung nur nach Größe...)
Vor Allem scheint die komprimierte Übertragung nicht immer gut zu laufen. Woran das jeweils hängt, ist mir nicht klar.

Gerade bei den beschriebenen Platten könnte ich mir deshalb eine Lösung mit tar sehr gut vorstellen oder vielleicht sogar ein Schreiben direkt auf das Gerät, ohne eigenes Dateisystem. Jedenfalls würde ich damit noch etwas spielen und nicht nur an rsync hängen.
 
ja... Für meine server nutze ich zfs mit snapshots, send und receive... Ist sehr performant! Gerade bei grossen Dateien, die nur ein paar Bytes dazu bekommen haben, natürlich viel, viel schneller... Aber zu Hause reicht mir rsync. Bei den anderen Festplatten ohne SMR ist die Performance ja gut. Ich liege bei einer Transferrate von 70-100 MB/sec. Das schwankt ein wenig. Aber das reicht mir und ich habe ja "nur" ein 1Gbit Netz zu Hause... Vielen Dank @pit234a :-) VG Norbert
 
Aber zu Hause reicht mir rsync
das reicht natürlich auch, aber es ist eben unter Umständen nicht so performant. Je nach Wunsch und Optionen.
Kennst du in dem Zusammenhang grsync?
Ich bin kein großer Fan davon, aber die ein oder andere Option hatte ich in der man überlesen und fand sie erst, nachdem ich sie in der gui gelesen hatte. Ist vielleicht auch mal einen Versuch Wert.
 
Zurück
Oben