SMR Platte mit LUKS deutlich schneller als unverschlüsselt. Warum?

[NixMehrFrei]

Guten Morgen. Ich habe mich vor einiger Zeit zähneknirschend für eine SMR Platte (als Zweitplatte) für meinen Laptop entschieden. Die reguläre Platte ist eine Samsung 850 Pro SSD mit 256 GByte, der Platz war aber knapp, ich brauchte mindestens 2 TByte.
Also entschied ich mich nach einer Kosten/Nutzen Abschätzung für eine HDD statt SSD die ich mittels Adapter in den Laufwerksschacht des DVD Brenner steckte. CMR Platten mit 9,5 mm Bauhöhe über 1 TByte gibt es nicht.

Meine ersten Gehversuche mit der SMR Platte waren so übel, das ich die Platte bereits nach zwei Tagen wieder ausbaute und schon in den Müll kloppen wollte.
Ich benutze Linux.
Root Partition, Swap und Home Partition ist auf der SSD, die HDD dient als Datengrab mit nur einer großen Partition die nur bei Bedarf gemountet wird.

Irgendwann spielte ich damit aber nochmal herum.
Dabei stellte ich etwas sehr interessantes fest das ich mir nicht erklären kann und hoffe, das ihr eine adäquate Idee habt, woran das liegen kann.
Der Effekt ist reproduzierbar und deutlich zu sehen.
Wenn die HDD nicht verschlüsselt ist, bricht die Datenrate nach 15-20 GByte auf mindestens 15 MByte/s zusammen, manchmal auf unter 5 MByte/s ... das ist natürlich völlig unakzeptabel und befähigt die Platte nur, auf den Müll zu fliegen.

Sobald die HDD aber mit LUKS verschlüsselt ist, steigt die Datenrate auf 80-100 MByte/s für die ersten 15-20 GByte und bricht dann auf auf schlimmstenfalls 30 MByte/s zusammen, meistens aber eher 35-40 MB/s, ein Wert mit dem ich bei einem Datengrab leben kann.

Ich weiß wie SMR funktioniert und kenne die Probleme von SMR, aber ich kann mir nicht erklären wie eine Laufwerksverschlüsselung so einen drastischen Effekt haben kann.

Aber warum ist das so? Jemand eine Idee?

Ich würde gerne den technischen Hintergrund verstehen.


Edit: Tippfehler

 

[tollertyp]

Ist die angezeigte Rate auch wirklich korrekt? Hast du mal Messungen gemacht, wie sich die Dauer tatsächlich verhält?
Wie voll war die Platte zum Zeitpunkt der beiden "Tests"?

Und je nachdem, wie dein Nutzungsszenario ist (also wie viel du auf die HDD schreibst) ist SMR halt mehr oder weniger schlimm (bei QLC bei SSDs ist das ja auch der Fall).

 

[NixMehrFrei]

Die Festplatte war in beiden Fällen leer.
Selbstverständlich habe ich überprüft ob das Ergebnis stimmt.
Datenrate passt gerundet zur Datenmenge und verlaufener Zeit.
Mein gesamter Datenbestand beläuft sich nur auf etwa einem Terabyte. Ich bin kein Jäger und Sammler.

 

[IBISXI]

Irgendeine Komprimierung aktiv?

LZ4 vielleicht?

 

[NixMehrFrei]

Nein, gar nix.
Der einzige Unterschied ist, das ich die unverschlüsselte Partition gelöscht habe, und eine mit LUKS neu erstellt habe.
Keine Komprimierung, keine exotischen Extras.
Deswegen ist das für mich so interessant.
Ich habe erst überlegt ob die Verschlüsselung eine Veränderung bewirkt, wie die Daten auf die Platter geschrieben werden.
Aber bei näherer Überlegung finde ich keinen Anhaltspunkt dazu.
Ich kann mir keinen Reim drauf machen was sich durch die Verschlüsselung ändert, ebenso bin ich mit den Tiefen der LUKS Verschlüsselung nicht vertraut genug.
Ich weiß nicht was diese im Hintergrund noch macht (ausser nur verschlüsseln).


EDIT: Bei der HDD handelt es sich um eine Toshiba L200 2 TB (SMR) 2,5"

 

[Hancock]

Kann es sein, dass sich die Blockgröße durch LUKS ändert? Da sollten SMR relativ empfindlich drauf reagieren.

 

[NixMehrFrei]

Interessante Idee, ich hab das mal eben überprüft mit einer kleinen Testpartition am Ende der HDD.

"sudo fdisk -l /dev/sdc1" gibt mir folgendes raus:

Festplatte /dev/sdc1: 1,78 TiB, 1940399325184 Bytes, 3789842432 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes

"sudo fdisk -l /dev/sdc2" dann das.

Festplatte /dev/sdc2: 55,9 GiB, 59998470144 Bytes, 117184512 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes

Sieht identisch für mich aus.

 

[snaxilian]

CMR Platten mit 9,5 mm Bauhöhe über 1 TByte gibt es nicht.

Puuuh, gewagte Aussage denn warum finde ich in 30 Sekunden gleich 4 Stück mit den Anforderungen von denen eine sogar 2 TB hat? https://geizhals.de/?cat=hde7s&xf=1080_SATA+1.5Gb/s~1080_SATA+3Gb/s~1080_SATA+6Gb/s~14771_9.5~3772_2.5~8457_Conventional+Magnetic+Recording+(CMR)~958_1500

Aber zum eigentlichen Grund des Threads zurück:
Unter der Annahme, dass du halbwegs aktuelle Hardware und ein ebenso halbwegs aktuelles OS nutzt kann das beobachtete Verhalten korrekt sein. Kopier- & Schreibvorgänge werden gerne parallelisiert, sprich mehrere Threads verarbeiten die Daten, ergo parallele Zugriffe auf das Dateisystem und damit das darunter liegende Laufwerk. Gerade bei SMRs ist das natürlich kontroduktiv und bremst dich ziemlich schnell ziemlich stark aus.

Der Grund warum es bei Verwendung von LUKS/dm-crypt schneller ist wird im verwendeten Cipher bzw. dem Block Cipher Encryption Mode liegen. Diese sind bei der Verschlüsselung nicht (alle?) parallelisierbar, lediglich das entschlüsseln lässt sich parallelisieren.

Nutzt du jetzt also LUKS dann schickt dein Dateimanager (bzw. am Ende das OS) mehrere parallele Copy-Threads an dein Dateisystem (dev/mapper/crypto), das gibt das weiter an LUKS was es letztendlich als ein Thread und damit schön linear auf /dev/sdb schreibt.

Vermutlich bekommst du ähnliche Performance auch ohne LUKS hin wenn das OS davon "weiß", dass das Laufwerk nur SMR kann oder ggf. gibt es entsprechende Mount-Parameter um Schreibzugriffe nicht zu parallelisieren.

 

[NixMehrFrei]

@snaxilian

Dankeschön!
Das ist eine bestens nachvollziehbare Erklärung.
Stimmt, die Symptome könnten genau dazu passen.

Auf mobilen Geräten verschlüssel ich meine Daten zwar grundsätzlich mit LUKS, aber es gibt auch Szenarien wo das nicht nötig ist.
Was die HDD betrifft, ich habe mir die vor der Coronakiste gekauft, ist etwa nen halbes Jahr her.
Ich hab exakt genau so gesucht wie du, sogar auf der selben Seite.
Leider waren damals noch keine 2.5" HDDs (2 TB) mit CMR verfügbar, wobei die aktuellen 2.5" HDDs mit 2 TB ja offensichtlich schon an SSD Preise rankommen.

 

[tollertyp]

Nichts für ungut, aber https://geizhals.de/samsung-spinpoint-m9t-1-5tb-st1500lm006-a1135991.html?hloc=at&hloc=de ist seit über 6 Jahren gelistet... ;-)
Also wer weiß, was für Filter du gesetzt hattest ^^

 

[NixMehrFrei]

Alles gut.
Ich wollte 2 TB.
Was kleineres ist also im Filter hängengeblieben.
Und natürlich, Bedienungsfehler sind nie ausgeschlossen.

 

[niteaholic]

Das wäre doch ein Fall für unseren @Holt, denke eher könnte da eher eine Erklärung liefern.

 

[kieleich]

Mit deinem fdisk-Befehl hast du leider gar nichts überprüft.

Du kannst /proc/sys/vm/block_dump anschalten, das knallt dir dann erstmal das Kernellog voll (jeder Lese-/Schreibzugriff und dessen Blockgröße). Ggf. von einer LiveCD aus oder bei Systemd mal kurz das Syslog abknipsen sonst ist deine SSD / dein rootfs schneller voll als dir lieb ist.

Wenn es an unterschiedlicher Blockgröße/Reihenfolge liegt kannst du das so feststellen.

Ansonsten, wieviel RAM hat die Kiste? Es kann auch gut sein daß mit LUKS als Zwischenschicht das Cache-Verhalten anders ist. Wie lange es dann wirklich dauert, weisst du erst nach sync/umount.

 

[NixMehrFrei]

Danke kieleich, mit dem fdisk Befehl wollte ich nur die Blockgröße ermitteln, mehr nicht.
snaxilian konnte meine Frage exzellent beantworten.
Bei der Kiste handelt es sich um einen Dell Latitude E5430 mit 8 GByte RAM.
Ich hab diesen etwas umgebaut (SSD statt HDD und ZweitHDD statt DVD).
Die CPU ist ein i5-3340M.
Das OS ist Linux Mint 20 64-Bit Cinnamon.
Linux Mint ist das einzige OS das ich produktiv benutze.
Ein Linux Geek bin ich nicht, ich bin erst zu Zeiten von Windows 7 zu Linux gewechselt.
Aus den üblichen Gründen.
Ich bin also immer offen für Tipps und Ratschläge derer, die schon länger dabei sind.

Wie gesagt, meine Frage jedoch wurde sehr zufriedenstellend beantwortet.

 

[kieleich]

......

 

[Holt]

CMR Platten mit 9,5 mm Bauhöhe über 1 TByte gibt es nicht.

Gibt es, aber die Modelle sind nicht mehr aktuell, also entweder überlagerte Restposten oder gebrauchte mit zurückgesetzten S.M.A.R.T. Werte, ich würde die Fingen davon lassen. 9,5mm Bauhöhe ist am Aussterben und bei 2.5" dominiert SMR, weil bisher nur mit SMR 1TB pro 2.5" Platter machbar ist.

Ich weiß wie SMR funktioniert und kenne die Probleme von SMR, aber ich kann mir nicht erklären wie eine Laufwerksverschlüsselung so einen drastischen Effekt haben kann.

Dies dürfte an den Zugriffen liegen, bei SMR ist die Performance umso schlechter, je kürzer die Zugriffe sind, also je weniger Daten pro Befehl geschrieben werden. Bei ATA kann ein Befehl ja bis zu 2^16 aufeinanderfolgende LBAs adressieren.

Ich habe erst überlegt ob die Verschlüsselung eine Veränderung bewirkt, wie die Daten auf die Platter geschrieben werden.
Aber bei näherer Überlegung finde ich keinen Anhaltspunkt dazu.

kieleich hat geschrieben wie man die Länge der Zugriffe vergleichen kann.

Sieht identisch für mich aus.

Das sind ja auch die physikalischen Eigenschaften der Platte, dies sagt aber nichts über die Clustergröße des Filesystems aus.

Du kannst /proc/sys/vm/block_dump anschalten, das knallt dir dann erstmal das Kernellog voll (jeder Lese-/Schreibzugriff und dessen Blockgröße). Ggf. von einer LiveCD aus oder bei Systemd mal kurz das Syslog abknipsen sonst ist deine SSD / dein rootfs schneller voll als dir lieb ist.

Damit sollte man sehen können, ob es an der Länge der Zugriffe liegt.

Was snaxilian bzgl. der parallelen Zugriffe schreibt, kann ich mir nicht vorstellen, da sich bei jeder HDD wegen der Kopfbewegungen parallele Zugriffe immer gegenseitig ausbremsen und daher wäre es unsinnig hier überhaupt parallele Zugriffe für einen einfachen Kopiervorgang zu machen.

 

[snaxilian]

@Holt Naja bei SSDs macht das schon Sinn Zugriffe zu parallelisieren. Ich weiß nicht wie sich Mint da verhält (was der TE ja nutzt) ob dies bei der Installation auf Vorhandensein einer SSD prüft und dann ggf. den I/O Scheduler ändert um Zugriffe zu optimieren. Kommt jetzt zu der SSD eine HDD hinzu wird afaik nicht der Scheduler geändert, ergo parallele Zugriffe auf die HDD. Ein vorhandenes Luks bzw. besser gesagt der CBC Cipher packt das alles wieder in eine serielle IO Queue.

Zumindest klingt das für mich sehr plausibel und würde die beobachteten Werte erklären. Aber vielleicht kommen ja noch andere Erkenntnisse oder Thesen, die das Verhalten besser erklären.

Übersicht der IO Scheduler: https://wiki.ubuntu.com/Kernel/Reference/IOSchedulers
Übersicht zu CBC: https://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode

 

[Holt]

Naja bei SSDs macht das schon Sinn Zugriffe zu parallelisieren.

Zumindest wenn es keine der DRAM less SSDs ist, aber die SSDs haben auch kein SMR und hier geht es um HDDs. Das Betriebssystem sollte schon erkennen bei welchem Laufwerk es sich um eine HDD handelt und dann den passenden I/O Scheduler für jedes Laufwerk entsprechend auswählen, bzw. kann man dies auch selbst, wie aus dem erste Link von Dir zu entnehmen ist:

Changing an I/O scheduler is performed on a per block device basis. For example, for non-multi queue device /dev/sda one can see the current I/O schedulers available using the following:

cat /sys/block/sda/queue/scheduler
noop deadline [cfq]

Zumindest klingt das für mich sehr plausibel und würde die beobachteten Werte erklären.

Klar, aber nur wenn beim Kopieren der Datei dann auch parallele Zugriffe entstehen und da ja wohl von der SSD auf die HDD kopiert wurde, ist dies normalerweise eher nicht zu erwarten, aber nur eine Analyse der Zugriffe würde Gewissheit bringen.