[Fedora] btrfs+encryptie = trage schijf

[foxgamer2019]

Kunnen jullie mij helpen?

Ik draai nu een maand Fedora Silverblue, maar de root partitie (Samsung 980 NVMe) is heel erg langzaam.
Als ik bijvoorbeeld via Steam een spel installeer, dan hangt mijn hele systeem vast.

Ik gebruik de default settings, zoals Btrfs en encryptie (door de wizard), maar ik heb geen idee waar het aan ligt?

[Voor 255% gewijzigd door foxgamer2019 op 14-12-2022 21:16]

[LievenD]

Hm, standaad instellingen zeg je?

Standaard lijkt mij meer iets als ext4 zonder encryptie.

Hoe groot is je root partitie? Ik had ergens online de raad gekregen om bij een SSD niet de volledige ruimte te partitioneren, maar om een klein deel (7% is genoeg) ongeformatteerd te laten. Dat zou de snelheid van de schijf ten goede komen. Nu weet ik niet of dit effectief helpt, maar ik heb in ieder geval nooit het gevoel gehad dat de schijf traag werd, en het gaat hier nog om een relatief kleine (250 GB) Samsung 840 Evo SATA SSD.

[Ultraman]

Ik heb wel een vermoeden: zou kunnen dat je tegen een I/O beperking aan loopt door work queues van dm-crypt (de disk encryptie). De encryptie is CPU technisch bijna gratis tegenwoordig, maar het huidige ontwerp van de lagen die de encryptie in de storage regelen laat te wensen over. Er zijn veel queues gemaakt die niet meer nodig zijn.

Leesvoer: https://blog.cloudflare.c...up-linux-disk-encryption/

Die work queues kun je, in recente kernels (5.9+), uitschakelen door die optie te zetten voor de disk encryptie. Dat kan met behulp van de cryptsetup utility waarmee tijdens de installatie ook je encrypted volume is gemaakt.

Aangezien je Fedora Silverblue gebruikt is je kernel recent genoeg. Ik neem even aan dat die up-to-date is?
Wat we nog moeten weten is de naam van de encrypted partitie van je disk. Daar moet namelijk de optie voor gezet worden.

Open eens een terminal en typ eens: lsblk
Dat geeft een boompje van je schijven en mountpoints. Op mijn laptop, met Fedora 35:

code:

$ lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
zram0                                         252:0    0     8G  0 disk  [SWAP]
nvme0n1                                       259:0    0 238,5G  0 disk  
├─nvme0n1p1                                   259:1    0   200M  0 part  /boot/efi
├─nvme0n1p2                                   259:2    0     1G  0 part  /boot
├─nvme0n1p3                                   259:3    0     6G  0 part  
└─nvme0n1p4                                   259:4    0 231,3G  0 part  
  └─luks-5a35890b-30c6-4fd5-8324-562a5feab0b9 253:0    0 231,3G  0 crypt /var/lib/machines
                                                                         /var/lib/libvirt/images
                                                                         /var/lib/containers
                                                                         /home
                                                                         /

In mijn geval is luks-5a35890b-30c6-4fd5-8324-562a5feab0b9 het dm-crypt mapped device in kwestie, dus: /dev/mapper/luks-5a35890b-30c6-4fd5-8324-562a5feab0b9.

Ik geef daarom op mijn machine:

code:

$ sudo cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue --persistent refresh /dev/mapper/luks-5a35890b-30c6-4fd5-8324-562a5feab0b9
Enter passphrase for /dev/nvme0n1p4: 
This operation is supported only for LUKS2 device.
Device activated but cannot make flags persistent.

Kan zijn dat hij eerst nog om het sudo wachtwoord vraagt. Die had ik in mijn geval al ergens anders voor gegeven en die zat nog unlocked in de sessie om die reden. Het wachtwoord voor /dev/nvme0n1p4 is het disk encryptiewachtwoord die je bij boot telkens in dient te geven.

In mijn geval kan hij het niet permanent zetten omdat mijn encrypted device (LUKS) nog een oude LUKS1 header heeft ipv een recentere LUKS2 header. De installatie op deze laptop is zijn leven ooit begonnen als Fedora 29. Omzetten van LUKS1 naar LUKS2 is trouwens vrij triviaal, dus dat zou ik best even kunnen doen. Alleen komt er voor mij rond de kerstperiode een nieuwe laptop aan op de zaak... daarom heb ik dat nog niet gedaan

[Voor 4% gewijzigd door Ultraman op 14-12-2022 22:29]

[foxgamer2019]

LievenD schreef op woensdag 14 december 2022 @ 22:00:
Hm, standaad instellingen zeg je?

Standaard lijkt mij meer iets als ext4 zonder encryptie.

Hoe groot is je root partitie? Ik had ergens online de raad gekregen om bij een SSD niet de volledige ruimte te partitioneren, maar om een klein deel (7% is genoeg) ongeformatteerd te laten. Dat zou de snelheid van de schijf ten goede komen. Nu weet ik niet of dit effectief helpt, maar ik heb in ieder geval nooit het gevoel gehad dat de schijf traag werd, en het gaat hier nog om een relatief kleine (250 GB) Samsung 840 Evo SATA SSD.

Helaas niet. Fedora kiest voor Btrfs als root, ik heb inderdaad encryptie (luks) gekozen, dat is niet standaard - maar ik bedoelde hier de wizard volgen mee.

1TB - 760GB vrij, regelmatig getrimt, etc. misschien ligt het aan de rpm-ostree of aan Btrfs?

[Ultraman]

Ik heb hiervoor op mijn gamebakkie ook Steam op btrfs gehad, weliswaar op een HDD destijds, en dat deed het uitstekend. Die disk was niet encrypted.
Toevallig kwam ik recent langs dat Cloudflare artikel.
Op Reddit is hij ook voorbij gekomen: https://www.reddit.com/r/...installed_on_dmcrypt_and/ en daar wordt ook gestotter bij het downloaden van Steam games genoemd door mensen.

Ben benieuwd of het je helpt.

[foxgamer2019]

Ultraman schreef op woensdag 14 december 2022 @ 22:09:
[..]

Thanks voor de leesvoer.

Het moet wel inderdaad iets I/O zijn, het gebeurd bij mij altijd als ik doe waarbij er flink geschreven wordt naar de disk (Steam, Torrents, SAB, ..), alles hangt en ik krijg letterlijk de ene freeze naar de andere.

Op Arch Linux had ik dit niet, maar ik kan nu niet meer terug.. of ja, het kan wel, maar om weer alles opnieuw te installeren..

Mijn lsblk:

code:

zram0               252:0    0     8G  0 disk  [SWAP]
nvme0n1             259:0    0 931,5G  0 disk  
├─nvme0n1p1         259:1    0   600M  0 part  /boot/efi
├─nvme0n1p2         259:2    0     1G  0 part  /boot
└─nvme0n1p3         259:3    0 929,9G  0 part  
  └─luks-..
                    253:0    0 929,9G  0 crypt /var/lib/docker/btrfs
                                               /var/home
                                               /var
                                               /sysroot/ostree/deploy/fedora/var
                                               /usr
                                               /etc
                                               /
                                               /sysroot

Dit is iets dat Fedora allemaal voor mij regelt, ik heb deze keer eens niet voor eigen partities gekozen.
Volgens mij is /var/lib/docker/btrfs is virtuele mapping.

Kan ik de huidige crypt flags ook ergens ophalen?

[Ultraman]

Mijn partitionering is ook door de Fedora installer geregeld destijds. Die is aardig gelijk aan de jouwe, alleen zijn de mount points wat anders.

Het device welke jij moet hebben is net degene die je geknipped hebt: /dev/luks-..

Of je de huidige cryptflags kunt uitpoepen moet ik even opzoeken. Dat kan vast maar ik schud niet zo uit de mouw hoe. Gokje: cryptsetup kan dat. Als ik het vind edit ik wel even.
Die workqueues staan default aan overigens.

[Voor 3% gewijzigd door Ultraman op 14-12-2022 22:18]

[foxgamer2019]

Ultraman schreef op woensdag 14 december 2022 @ 22:13:
Ik heb hiervoor op mijn gamebakkie ook Steam op btrfs gehad, weliswaar op een HDD destijds, en dat deed het uitstekend. Die disk was niet encrypted.
Toevallig kwam ik recent langs dat Cloudflare artikel.
Op Reddit is hij ook voorbij gekomen: https://www.reddit.com/r/...installed_on_dmcrypt_and/ en daar wordt ook gestotter bij het downloaden van Steam games genoemd door mensen.

Ben benieuwd of het je helpt.

Nu ik mij bedenk.. op Arch Linux gebruikte ik linux-zen als kernel, die deed dus schijnbaar niet aan die threads queue.

Is het mogelijk de huidige flags eerst op te vragen? Ik ben een beetje huiverig om dit zomaar uit te voeren op mijn machine.

Gevonden: https://wiki.archlinux.org/title/Dm-crypt/Specialties - morgen maar eens proberen.

[Voor 5% gewijzigd door foxgamer2019 op 14-12-2022 22:24]

[Ultraman]

Dat commando kun je veilig uitvoeren. Je data is niet at risk. Het zet gebruik van de work queues uit voor lezen en schrijven. Je zou die --persistent vlag weg kunnen laten, dan is het alleen runtime en schrijft hij niets naar disk.

Kijk eens wat er bij jou uit commando:

code:

$ sudo cryptsetup luksDump /dev/nvme0n1p3

komt zetten? Dat dumpt de inhoud van de LUKS header (vanaf disk) naar de terminal.

In mijn geval staan daar geen vlaggen bij omdat ik een LUKS1 header heb.
Ik zal mijn header eens omzetten naar een LUKS2 voor de vorm, zodat ik zie wat jij ziet.

[Voor 3% gewijzigd door Ultraman op 14-12-2022 22:30]

[Ultraman]

Ja, die afsplitsing van topic zag ik wel aankomen @Hero of Time

[Ultraman]

Nog een dump commando voor de "runtime" omgeving:

code:

$ sudo dmsetup table
luks-5a3..: 0 485015552 crypt aes-xts-plain64 ..knip.. no_read_workqueue no_write_workqueue

Bij mij zijn de vlaggen runtime actief nu.

[Voor 10% gewijzigd door Ultraman op 14-12-2022 22:29]

[foxgamer2019]

Ik wil niet te vroeg juichen.. maar dit lijkt het probleem te hebben opgelost!

Nu morgen nog even SAB testen, daar ging hij helemaal stuk op. Maar ik haal nu ~65MB/s zonder problemen en freezes.

@Ultraman Thanks voor de fix! Nu doet zelfs het downloaden het weer goed.
Voorheen kreeg ik ontzettende CPU spikes en freezes, die lijken nu voorbij.

Morgen nog verder testen.

[Voor 31% gewijzigd door foxgamer2019 op 14-12-2022 22:50]