Performance mit Luks

[DatAres]

Hallo werte Computerbase-Gemeinde,

Ich möchte meinen PC demnächst komplett neu aufsetzen und plane aktuell diesen auch entsprechend zu verschlüsseln. Gibt es hier Erfahrungen, mit welchen Performance-Einbußen man damit zu rechnen hat? Vor allem im Bezug auf eine NVMe. Ich finde hierzu gemischte Aussagen irgendwo zwischen "Merkt man nicht mit aktueller Hardwareunterstützung" bis hin zu "Meine NVMe hat die Hälfte ihrer Geschwindigkeiten". Kann ich davon ausgehen, den Unterschied mit aktueller Hardware nicht zu merken? Vielleicht kann hier jemand seine Erfahrungen oder auch bestenfalls ein paar Zahlen teilen.

 

[Kaito Kariheddo]

Wenn du gerade schon ein laufendes System hast (oder mal eben ein Live System startest) kannst du mit (sudo) cryptsetup benchmark dir anschauen, wie die Werte bei dir sind. Der gängige Wert ist unten aes-xts bei 512er Schlüssel. Du solltest eine PCI-e 3 voll Auslasten und eine PCI-e 4 zumindest teilweise
Edit: Mit

sudo cryptsetup -c aes-xts-plain64 -s 512 benchmark

kannst du dir auch direkt die Werte für die gängige Verschüsselung anzeigen lassen

 

[Fujiyama]

Habe einige Zeit Veracrypt verwendet, die Gefühlte Geschwindigkeitseinbuße war 0.
Nen Benchmark hab ich aber nie drüber laufen lassen.

 

[0x7c9aa894]

Wenn man NVMe verschlüsseln willst, und die Performance gut sein soll, denn würde ich OPAL, also Selbstverschlüsslung mal in Betracht ziehen, soweit es dein Risikoszenario zulässt.

 

[foofoobar]

Vielleicht kann hier jemand seine Erfahrungen oder auch bestenfalls ein paar Zahlen teilen.

AMD Ryzen 7 3700X && Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961/SM963

# fio --readonly --direct=1 --name=test --size=16G --bs=4k --rw=randread --filename=/dev/mapper/nvme0n1p5_crypt --numjobs=8 --ioengine=libaio --iodepth=2 --group_reporting
test: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=2
...
fio-3.25
Starting 8 processes
Jobs: 2 (f=1): [(2),r(1),(3),f(1),_(1)][100.0%][r=996MiB/s][r=255k IOPS][eta 00m:00s]
test: (groupid=0, jobs=8): err= 0: pid=1697813: Fri Jun 10 21:16:39 2022
read: IOPS=359k, BW=1404MiB/s (1472MB/s)(128GiB/93367msec)
slat (nsec): min=1360, max=856270, avg=3646.34, stdev=1284.10
clat (nsec): min=440, max=8347.0k, avg=39747.61, stdev=27294.99
lat (usec): min=15, max=8350, avg=43.51, stdev=27.35
clat percentiles (usec):
| 1.00th=[ 19], 5.00th=[ 22], 10.00th=[ 23], 20.00th=[ 25],
| 30.00th=[ 27], 40.00th=[ 29], 50.00th=[ 30], 60.00th=[ 32],
| 70.00th=[ 35], 80.00th=[ 39], 90.00th=[ 88], 95.00th=[ 100],
| 99.00th=[ 139], 99.50th=[ 153], 99.90th=[ 182], 99.95th=[ 196],
| 99.99th=[ 233]
bw ( MiB/s): min= 1356, max= 1482, per=100.00%, avg=1414.95, stdev= 2.84, samples=1479
iops : min=347350, max=379567, avg=362227.84, stdev=726.76, samples=1479
lat (nsec) : 500=0.01%, 750=0.01%, 1000=0.01%
lat (usec) : 2=0.01%, 4=0.01%, 10=0.01%, 20=2.36%, 50=82.06%
lat (usec) : 100=10.81%, 250=4.76%, 500=0.01%, 750=0.01%, 1000=0.01%
lat (msec) : 2=0.01%, 4=0.01%, 10=0.01%
cpu : usr=7.43%, sys=23.85%, ctx=25927557, majf=0, minf=119
IO depths : 1=0.1%, 2=100.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=33554432,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=2

Run status group 0 (all jobs):
READ: bw=1404MiB/s (1472MB/s), 1404MiB/s-1404MiB/s (1472MB/s-1472MB/s), io=128GiB (137GB), run=93367-93367msec


# fio --readonly --direct=1 --name=test --size=16G --bs=64k --rw=randread --filename=/dev/mapper/nvme0n1p5_crypt --numjobs=8 --ioengine=libaio --iodepth=2 --group_reporting
test: (g=0): rw=randread, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=libaio, iodepth=2
...
fio-3.25
Starting 8 processes
Jobs: 8 (f=8): [r(8)][100.0%][r=3051MiB/s][r=48.8k IOPS][eta 00m:00s]
test: (groupid=0, jobs=8): err= 0: pid=1697842: Fri Jun 10 21:17:42 2022
read: IOPS=48.5k, BW=3030MiB/s (3177MB/s)(128GiB/43258msec)
slat (nsec): min=2430, max=62560, avg=7251.64, stdev=1701.73
clat (usec): min=102, max=6162, avg=321.16, stdev=97.86
lat (usec): min=109, max=6223, avg=328.55, stdev=97.84
clat percentiles (usec):
| 1.00th=[ 219], 5.00th=[ 241], 10.00th=[ 251], 20.00th=[ 265],
| 30.00th=[ 273], 40.00th=[ 281], 50.00th=[ 289], 60.00th=[ 302],
| 70.00th=[ 322], 80.00th=[ 355], 90.00th=[ 437], 95.00th=[ 523],
| 99.00th=[ 701], 99.50th=[ 783], 99.90th=[ 988], 99.95th=[ 1074],
| 99.99th=[ 1319]
bw ( MiB/s): min= 2971, max= 3103, per=100.00%, avg=3034.61, stdev= 3.07, samples=688
iops : min=47546, max=49658, avg=48553.77, stdev=49.07, samples=688
lat (usec) : 250=9.88%, 500=84.09%, 750=5.36%, 1000=0.58%
lat (msec) : 2=0.09%, 4=0.01%, 10=0.01%
cpu : usr=1.21%, sys=6.05%, ctx=2053372, majf=0, minf=356
IO depths : 1=0.1%, 2=100.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=2097152,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=2

Run status group 0 (all jobs):
READ: bw=3030MiB/s (3177MB/s), 3030MiB/s-3030MiB/s (3177MB/s-3177MB/s), io=128GiB (137GB), run=43258-43258msec
#




# fio --readonly --direct=1 --name=test --size=16G --bs=4k --rw=randread --filename=/dev/nvme0n1p5 --numjobs=8 --ioengine=libaio --iodepth=2 --group_reporting
test: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=2
...
fio-3.25
Starting 8 processes
Jobs: 4 (f=4): [(1),r(2),(1),r(2),_(2)][100.0%][r=1608MiB/s][r=412k IOPS][eta 00m:00s]
test: (groupid=0, jobs=8): err= 0: pid=1697982: Fri Jun 10 21:33:05 2022
read: IOPS=444k, BW=1734MiB/s (1819MB/s)(128GiB/75576msec)
slat (nsec): min=980, max=50340, avg=2613.91, stdev=794.63
clat (nsec): min=430, max=5864.3k, avg=32394.06, stdev=27980.83
lat (usec): min=12, max=5888, avg=35.09, stdev=27.99
clat percentiles (usec):
| 1.00th=[ 15], 5.00th=[ 16], 10.00th=[ 17], 20.00th=[ 18],
| 30.00th=[ 20], 40.00th=[ 21], 50.00th=[ 23], 60.00th=[ 24],
| 70.00th=[ 26], 80.00th=[ 29], 90.00th=[ 81], 95.00th=[ 93],
| 99.00th=[ 137], 99.50th=[ 149], 99.90th=[ 184], 99.95th=[ 196],
| 99.99th=[ 231]
bw ( MiB/s): min= 1594, max= 1845, per=100.00%, avg=1746.23, stdev= 5.57, samples=1196
iops : min=408256, max=472566, avg=447034.54, stdev=1425.06, samples=1196
lat (nsec) : 500=0.01%, 750=0.01%, 1000=0.01%
lat (usec) : 2=0.01%, 4=0.01%, 10=0.01%, 20=35.08%, 50=49.54%
lat (usec) : 100=11.84%, 250=3.53%, 500=0.01%, 750=0.01%, 1000=0.01%
lat (msec) : 2=0.01%, 10=0.01%
cpu : usr=9.81%, sys=23.35%, ctx=26191475, majf=0, minf=138
IO depths : 1=0.1%, 2=100.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=33554432,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=2

Run status group 0 (all jobs):
READ: bw=1734MiB/s (1819MB/s), 1734MiB/s-1734MiB/s (1819MB/s-1819MB/s), io=128GiB (137GB), run=75576-75576msec

Disk stats (read/write):
nvme0n1: ios=33535056/111, merge=0/3, ticks=1044170/23, in_queue=1044203, util=99.95%


# fio --readonly --direct=1 --name=test --size=16G --bs=64k --rw=randread --filename=/dev/nvme0n1p5 --numjobs=8 --ioengine=libaio --iodepth=2 --group_reporting
test: (g=0): rw=randread, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=libaio, iodepth=2
...
fio-3.25
Starting 8 processes
Jobs: 8 (f=8): [r(8)][100.0%][r=3219MiB/s][r=51.5k IOPS][eta 00m:00s]
test: (groupid=0, jobs=8): err= 0: pid=1698021: Fri Jun 10 21:33:56 2022
read: IOPS=51.7k, BW=3233MiB/s (3390MB/s)(128GiB/40537msec)
slat (nsec): min=3730, max=56660, avg=5119.85, stdev=443.21
clat (usec): min=32, max=6205, avg=303.21, stdev=91.26
lat (usec): min=37, max=6261, avg=308.40, stdev=91.28
clat percentiles (usec):
| 1.00th=[ 212], 5.00th=[ 231], 10.00th=[ 247], 20.00th=[ 251],
| 30.00th=[ 265], 40.00th=[ 269], 50.00th=[ 277], 60.00th=[ 285],
| 70.00th=[ 285], 80.00th=[ 322], 90.00th=[ 412], 95.00th=[ 490],
| 99.00th=[ 676], 99.50th=[ 766], 99.90th=[ 963], 99.95th=[ 1057],
| 99.99th=[ 1254]
bw ( MiB/s): min= 3172, max= 3288, per=100.00%, avg=3235.27, stdev= 2.68, samples=648
iops : min=50766, max=52616, avg=51764.32, stdev=42.90, samples=648
lat (usec) : 50=0.01%, 100=0.01%, 250=19.67%, 500=75.70%, 750=4.07%
lat (usec) : 1000=0.48%
lat (msec) : 2=0.07%, 10=0.01%
cpu : usr=1.29%, sys=4.81%, ctx=2096595, majf=0, minf=358
IO depths : 1=0.1%, 2=100.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=2097152,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=2

Run status group 0 (all jobs):
READ: bw=3233MiB/s (3390MB/s), 3233MiB/s-3233MiB/s (3390MB/s-3390MB/s), io=128GiB (137GB), run=40537-40537msec

Disk stats (read/write):
nvme0n1: ios=2090676/35, merge=0/1, ticks=634808/30, in_queue=634846, util=99.78%
#

 

[lordlaschi]

Ich finde hierzu gemischte Aussagen irgendwo zwischen "Merkt man nicht mit aktueller Hardwareunterstützung" bis hin zu "Meine NVMe hat die Hälfte ihrer Geschwindigkeiten"

Die beiden Aussagen schließen einander ja nicht aus. Die allermeisten Nutzer werden nicht merken ob sie eine sata sdd oder pcie3 oder pcie4 nvme ssd haben. Liegt daher eher an deinem Nutzungszenario. Powernutzer die regelmäßig hunderte GB schreiben und ausreichend schnelle Quell-/Ziellaufwerke haben merken da vll. schon etwas. Prinzipiell sind aktuelle CPUs aber schnell genug um mehrere GB/s mit AES zu encodieren, siehe: https://images.anandtech.com/graphs/graph17047/127232.png

 

[DatAres]

Wenn du gerade schon ein laufendes System hast (oder mal eben ein Live System startest) kannst du mit (sudo) cryptsetup benchmark dir anschauen, wie die Werte bei dir sind.

Hab ich leider nicht, daher die Frage.

Wenn man NVMe verschlüsseln willst, und die Performance gut sein soll, denn würde ich OPAL, also Selbstverschlüsslung mal in Betracht ziehen, soweit es dein Risikoszenario zulässt.

Wäre eventuell auch eine Option, wobei ich gelesen habe, dass die Implementierung in der Firmware ab und zu nicht so optimal ist und sich auch mal Bugs einschleichen. Aber muss ich mir noch mal anschauen.

AMD Ryzen 7 3700X && Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961/SM963

Kenne das Tool jetzt nicht, aber liest sich denke ich ganz in Ordnung (?). Waren jetzt keine Writes dabei oder?

Gibt es eventuell auch noch einen Unterschied, ob man FDE macht oder nur einzelne Verzeichnisse verschlüsselt?

 

[Kaito Kariheddo]

https://openbenchmarking.org/test/s...e9412268976fd6f9c5bf69cce7f06caa1f278#metrics

Vielleicht hilft dir ja diese Liste weiter um abschätzen zu können welche Leistung dich erwartet ? Um welche CPU handelt es sich denn ?

 

[foofoobar]

Hab ich leider nicht, daher die Frage.

Wäre eventuell auch eine Option, wobei ich gelesen habe, dass die Implementierung in der Firmware ab und zu nicht so optimal ist und sich auch mal Bugs einschleichen. Aber muss ich mir noch mal anschauen.

Kenne das Tool jetzt nicht, aber liest sich denke ich ganz in Ordnung (?). Waren jetzt keine Writes dabei oder?

fio ist das Standard-Tool für Linux. Ich habe oben den Zugriff auf die "selbe" Partition einmal verschlüsselt (-filename=/dev/mapper/nvme0n1p5_crypt) und auf die drunter liegenden Partition (--filename=/dev/nvme0n1p5) mit random read und mit unterschiedlichen Blockgrößen verglichen.

Gibt es eventuell auch noch einen Unterschied, ob man FDE macht oder nur einzelne Verzeichnisse verschlüsselt?

Am besten immer die ganze Platte verschlüsseln, das ist am schnellsten und am sichersten.

Ergänzung (11. Juni 2022)

Wenn du gerade schon ein laufendes System hast (oder mal eben ein Live System startest) kannst du mit (sudo) cryptsetup benchmark dir anschauen, wie die Werte bei dir sind. Der gängige Wert ist unten aes-xts bei 512er Schlüssel. Du solltest eine PCI-e 3 voll Auslasten und eine PCI-e 4 zumindest teilweise

"cryptsetup benchmark" testet nur auf einem Core, dm-crypt kann sich auf mehrere Cores verteilen, und die Implementierung ist so gut das man davon auch beim linearen lesen mit "--numjobs=1" profitiert: (Und die IO-Queue gut gefüllt ist)

# cryptsetup -c aes-xts-plain64 -s 512 benchmark
# Tests are approximate using memory only (no storage IO).
# Algorithm | Key | Encryption | Decryption
aes-xts 512b 2625.1 MiB/s 2657.3 MiB/s
#
# fio --readonly --direct=1 --name=test --size=16G --bs=64k --rw=read --filename=/dev/mapper/nvme0n1p5_crypt --numjobs=1 --ioengine=libaio --iodepth=16 --group_reporting
test: (g=0): rw=read, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=libaio, iodepth=16
fio-3.25
Starting 1 process
Jobs: 1 (f=1): [R(1)][100.0%][r=3072MiB/s][r=49.2k IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=1704092: Sat Jun 11 07:46:13 2022
read: IOPS=48.2k, BW=3013MiB/s (3159MB/s)(16.0GiB/5438msec)
slat (nsec): min=2580, max=48900, avg=5831.28, stdev=929.54
clat (usec): min=223, max=6669, avg=325.36, stdev=144.97
lat (usec): min=229, max=6689, avg=331.31, stdev=145.05
clat percentiles (usec):
| 1.00th=[ 262], 5.00th=[ 265], 10.00th=[ 269], 20.00th=[ 285],
| 30.00th=[ 285], 40.00th=[ 285], 50.00th=[ 289], 60.00th=[ 302],
| 70.00th=[ 314], 80.00th=[ 326], 90.00th=[ 351], 95.00th=[ 416],
| 99.00th=[ 1188], 99.50th=[ 1237], 99.90th=[ 1303], 99.95th=[ 1352],
| 99.99th=[ 1483]
bw ( MiB/s): min= 2431, max= 3336, per=100.00%, avg=3016.76, stdev=279.96, samples=10
iops : min=38902, max=53390, avg=48268.20, stdev=4479.30, samples=10
lat (usec) : 250=0.26%, 500=96.07%, 750=0.99%, 1000=0.79%
lat (msec) : 2=1.88%, 10=0.01%
cpu : usr=6.58%, sys=37.36%, ctx=243636, majf=0, minf=265
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=262144,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
READ: bw=3013MiB/s (3159MB/s), 3013MiB/s-3013MiB/s (3159MB/s-3159MB/s), io=16.0GiB (17.2GB), run=5438-5438msec
#

Ergänzung (11. Juni 2022)

Wenn man NVMe verschlüsseln willst, und die Performance gut sein soll, denn würde ich OPAL, also Selbstverschlüsslung mal in Betracht ziehen, soweit es dein Risikoszenario zulässt.

dm-crypt bzw. luks ist gut genug um auf solchen fragwürdigen Kram locker verzichten zu können.
Schau dir die Vergleichswerte an die ich ich gepostet habe. Und es wäre auch zu zeigen die Verschllüsselung in der SSD wirklich besser als dm-crypt bzw. luks ist, hast du das mal verglichen?

 

[Kaito Kariheddo]

@foofoobar wieder was gelernt, danke

 

[Snowi]

Kommt letztlich auf den Algorithmus an, aber wie hier schon geschrieben wurde: Vermutlich sowieso nicht spürbar.

Habe mal zum Vergleich 2 Benchmarks auf meiner Hardware laufen lassen.

Spoiler: i5 12500

# Algorithm | Key | Encryption | Decryption
aes-cbc | 128b | 1767.6 MiB/s | 6925.2 MiB/s
serpent-cbc | 128b | 121.1 MiB/s | 902.1 MiB/s
twofish-cbc | 128b | 265.1 MiB/s | 593.5 MiB/s
aes-cbc | 256b | 1378.6 MiB/s | 5802.4 MiB/s
serpent-cbc | 256b | 125.7 MiB/s | 908.9 MiB/s
twofish-cbc | 256b | 271.0 MiB/s | 595.1 MiB/s
aes-xts | 256b | 5448.5 MiB/s | 5295.7 MiB/s
serpent-xts | 256b | 856.3 MiB/s | 848.5 MiB/s
twofish-xts | 256b | 561.0 MiB/s | 567.9 MiB/s
aes-xts | 512b | 4967.6 MiB/s | 4948.9 MiB/s
serpent-xts | 512b | 855.6 MiB/s | 873.4 MiB/s
twofish-xts | 512b | 572.3 MiB/s | 580.6 MiB/s

Spoiler: AMD Ryzen 7 4700U

# Algorithmus | Schlüssel | Verschlüsselung | Entschlüsselung
aes-cbc | 128b | 768,2 MiB/s | 2191,9 MiB/s
serpent-cbc | 128b | 74,0 MiB/s | 462,5 MiB/s
twofish-cbc | 128b | 142,1 MiB/s | 248,7 MiB/s
aes-cbc | 256b | 596,0 MiB/s | 1755,4 MiB/s
serpent-cbc | 256b | 72,4 MiB/s | 439,4 MiB/s
twofish-cbc | 256b | 156,4 MiB/s | 262,3 MiB/s
aes-xts | 256b | 1782,5 MiB/s | 1807,1 MiB/s
serpent-xts | 256b | 450,6 MiB/s | 446,0 MiB/s
twofish-xts | 256b | 267,7 MiB/s | 268,2 MiB/s
aes-xts | 512b | 1564,2 MiB/s | 1582,2 MiB/s
serpent-xts | 512b | 478,6 MiB/s | 462,8 MiB/s
twofish-xts | 512b | 271,5 MiB/s | 271,2 MiB/s

 

[Piktogramm]

Bei den schönen Werten mit euren CPUs, sollte man aber auch dazu schreiben, zu welchem Anteil die CPU an der Stelle ausgelastet ist. Der Durchsatz kommt ja nur zustande, wenn die CPU wirklich was tut, genauso wie Speicherbandbreite dafür zu veranschlagen ist. Seit AES-Ni und dicken CPUs in allen Geräten ist das weniger relevant, aber kostenlos gibt es das immer noch nicht.
Naja und es kommen zwangsweise Latenzen hinzu, was bei vielen kleinen I/O Zugriffen durchaus Auswirkungen haben kann.

Was bei Verschlüsselung und LUKS noch am ehesten Performance kostet ist, dass TRIM deaktiviert ist. Das ist der richtige, paranoide Standard und man sollte sich bewusst sein, ob man etwa Unsicherheit gegen langfristig bessere Performance tauscht.

 

[_roman_]

Performance-Einbußen man damit zu rechnen hat?

Hallo

Meine Gentoo Installation ist aus 2006.
Bei einem i7-3610QM mit einer SATA SSD hatte ich eher nicht viel Unterschied gemerkt in meinem Anwendungsgebiet mit einem Gaming Notebook.
Seit Circa 1 Jahr habe ich einen 5800x mit 2 PCIE4.0 NVME.

Für meine Desktop Dinge ist es schnell genug. Ich komme aber von einem Gaming Notebook.

Ich würde mir eher mehr Sorgen machen bezüglich Lebensdauer der Laufwerke. 2 von 5 SATA SSD Laufwerke (CRUCIAL / ADATA) hatte nach 3 Jahren Verwendung gewisse Alterserscheinungen aufgrund dessen ich diese entsorgen musste.

Vor allem im Bezug auf eine NVMe.

Ich habe Kopiertests gemacht mit Altagsdaten

Windows 10 Pro / Gentoo
Model Number: CT1000P5PSSD8

Datengrab Pcie 4.0 auf Pcie 3.0 angeschlossen - B550
Model Number: Corsair MP600 PRO

Die Übertragungsrate war unterirdisch für mich. Einerseits wird nie berücksichtigt welches große Daten und viele kleinere Daten unterschiedlich schnell kopiert werden. Anderseits ist es immer bis zu einer möglichen Mondpreis-Übertragungsrate. Welche sowohl in Windows als auch in Gnu Linux nie zu sehen ist!
Für mich ist PCIE 4.0 und PCIE 3.0 eher Marketing.

Einflussfaktoren auf die schlechte Performance sind das Mainboard, die NVME-Laufwerke, Das Dateisystem und LVM2 mit LUKS.

Ich finde hierzu gemischte Aussagen irgendwo zwischen "Merkt man nicht mit aktueller Hardwareunterstützung" bis hin zu "Meine NVMe hat die Hälfte ihrer Geschwindigkeiten". Kann ich davon ausgehen, den Unterschied mit aktueller Hardware nicht zu merken? Vielleicht kann hier jemand seine Erfahrungen oder auch bestenfalls ein paar Zahlen teilen.

Der Unterschied ist sehr deutlich merkbar wenn man Daten verschiebt vom LVM2/LUKS/EXT4 auf den neuen Treiber im Linux Kernel mit Windows formatierte NTFS NVME Disk. (nicht der ntfs-3g treiber)

Neuerdings habe ich eine merkbare Verzögerung wenn ich gewisse Ordner öffne. Diese enthalten z.b. ~115.000 Dateien mit einer Größe bis zu 10 MB. Irgendetwas braucht circa 3-5 Sekunden Nachdenkpause.

--

Man muss sich fragen warum man eine Vollverschlüsselung möchte?

Der Sinn einer Verschlüsselung ist nicht Geschwindigkeit.

Arbeiten konnte ich schon länger mit Vollverschlüsselung. Es reicht z.B. ein T9500 mit 4GIB RAM und 128GB SSD.

Ergänzung (12. Juni 2022)

Was bei Verschlüsselung und LUKS noch am ehesten Performance kostet ist, dass TRIM deaktiviert ist. Das ist der richtige, paranoide Standard und man sollte sich bewusst sein, ob man etwa Unsicherheit gegen langfristig bessere Performance tauscht.

TRIM ist nicht deaktiviert. Dies ist im Grunde eine falsche Aussage. Falsch Nachgesagt weil es irgendeiner Behauptet hat. Grundlagen, siehe fstab, und mountoptions.

Letztstand, wenn man discard option setzt in der fstab, sollte es sein wie trim, wenn der kernel und rest richtig konfiguriert ist. Will man dies haben mit einer LUKS-Verschlüsselung? Nein, weil man im Grunde verrät was alte Daten sind usw.

Ich habe regelmaessig meine Daten frisch auf eine neu aufgesetzte LVM2 / LUKS / EXT4 kopiert aufgrund meiner Backup Strategie. Ich habe da keinen Unterschied gesehen im REAL LIFE SZENARIO. vom Frisch kopiert auf bis zu 2 Monate alten System in Verwendung. Und da ich 5 verschiedene SATA SSDS mit 128GB in Verwendung hatte, kann man sagen dies ist herstellerunabhaengig der SATA SSDs. Ich gehe davon aus wenn man ein Laufwerk frisch aufsetzt, siehe Gentoo Handbuch als Referenz Startpunkt, ein SATA SSD sich neu initialisiert und deshalb TRIM im Grunde nutzloses feature ist. Was die Firmware dieser SATA SSDs macht, weis im Grunde keiner. Das neu anlegen einer Disk ist schneller als bestehende Daten zu löschen - neue Partitionstabelle, LVM2, LUKS, Filesystem

Im Grunde ist es in meiner persönlichen Meinung, ein großer Schwachsinn, herumzumotzen wegen TRIM, wenn ich auf einem Gaming Notebook mit SATA 6.0 mit einem i7 keinen Unterschied gesehen haben über mehrere Jahre. Der Performance impact vom fehlenden TRIM haette bemerkbar sein muessen wenn man auf so einem low performance System wie einem alten Gaming Notebook LVM2 und LUKS Layer hinzufuegt.

Das eine sind Theoretiker welches irgendetwas lesen und dann irgendetwas dann behaupten.
Das andere sind Personen welches so ein Setup über mehrere Jahre selbst verwenden als Hauptsystem.


Es ist ein alter HUT, Dateisysteme neu zu initialisieren und neu zu beschreiben nach einer gewissen Zeit. Deshalb muss man auch die Partitionstabelle und das File System neu anlegen.
Es macht auch Sinn dies mit einer regelmaessig neu aktualisiertem Wiederherstellungssystem durchzuführen, da es auch Änderungen an den Programme gibt welche diese Schritte durchführen. Sprich man hat kein altes Dateisystem mit "bugs" welche spaeter gefixt wurden.

Ergänzung (12. Juni 2022)

Gibt es eventuell auch noch einen Unterschied, ob man FDE macht oder nur einzelne Verzeichnisse verschlüsselt?

Vollverschlüsselung.

EFI STUB Kernel welches man mittels efibootmgr ins UEFI einbettet.

Rest macht keinen Sinn. - out of scope - gibt es genug webseiten wo man dann nachlesen kann - warum wieso usw.

 

[Piktogramm]

TRIM ist nicht deaktiviert. Dies ist im Grunde eine falsche Aussage. Falsch Nachgesagt weil es irgendeiner Behauptet hat. Grundlagen, siehe fstab, und mountoptions.

Solang im /etc/crypttab kein discard konfiguriert ist bzw. kein "allow-discard" Flag bei der Partition gesetzt ist sollte recht egal sein, was in /etc/fstab steht. Da mag der Dateisystemtreiber discards auf dem /dev/cryptdev durchführen, dmCrypt reicht es in Konsequenz jedoch nicht an die Hardware durch. Dmcrypt default ist dabei, kein Trim zu unterstützen, wobei die defaults in jeder Distribution natürlich abweichen können.

Und Nachgeplappert ist das aus der offiziellen Dokumentation: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt


Ansonsten ist es so wie schon in Post #6 erwähnt wurde. Halbierte Performance einer schnellen SSD und immer noch sehr schnelles Systemverhalten müssen sich nicht ausschließen. Bei Anwendungen, wo I/O der begrenzende Faktor wird, kann der Overhead und fehlendes TRIM jedoch wirklich nervig sein.

 

[lutzpime]

Ich benutze eine komplette Laufwerksverschlüsselung mit LUKS, mit Linux Mint 20.3 und bis auf die Bootzeit, kann ich im Alltag nichts Negatives feststellen. Wobei ich nur Surfe und ein bisschen Office mache. Falls ich mal etwas kopiere, begrenzt eher das externe Medium bzw. USB 3.0.
Meine Hardware ist auch schon etwas betagter: i7-4770, Samsung 860 EVO, 16 GB Ram. TRIM ist bei mir übrigens aktiviert, ohne dass ich etwas gemacht habe.

 

[DatAres]

Der Unterschied ist sehr deutlich merkbar wenn man Daten verschiebt vom LVM2/LUKS/EXT4 auf den neuen Treiber im Linux Kernel mit Windows formatierte NTFS NVME Disk. (nicht der ntfs-3g treiber)

Gut, so was hab ich nicht vor. Geht eher um einfaches Beschreiben und Lesen.

TRIM ist bei mir übrigens aktiviert, ohne dass ich etwas gemacht habe.

Ist mir bei Ubuntu Server auch schon aufgefallen, obwohl ich die Info hatte, dass das standardmäßig aus ist.

 

[Piktogramm]

Ist mir bei Ubuntu Server auch schon aufgefallen, obwohl ich die Info hatte, dass das standardmäßig aus ist.

Was sagt ~$ sudo cryptsetup luksDump /dev/sdX | grep Flags, wenn du die Partition mit dem Container abfragst und was steht in der /etc/crypttab?