zSwap vs. zRAM vs. zRAM-Disk

[andy_m4]

Ich dachte immer, systemd wäre das Beste was man unter Linux kriegen kann. :-)

runit

Ja. Das hat in der Tat einen gewissen Charme.

 

[Uridium]

softlevel=single ist explizit in der Wiki aufgeführt. Das hast Du ausprobiert?
https://wiki.artixlinux.org/Main/OpenRC

Artix-Xfce-openrc (die Cummunity-Edition

Was es nicht alles gibt...

 

[Caramon2]

bzgl openrc s. Ergänzung des hierhin verschobenen Beitrags: https://www.computerbase.de/forum/t...tung-bei-zfs-encryption.2112710/post-27490412

 

[Donnerkind]

Wie oben beschrieben, moute ich /tmp/ ins RAM (bei Solus übrigens nicht notwendig, da es das standardmäßig macht) und lasse beim Start dort den Ordner 'ramdisk" erstellen: Den habe ich als Lesezeichen im Dateimanager eingerichtet und nur darin arbeite ich. Alles andere unter /tmp/ ist nicht wichtig.

Anderes Prinzip, gleicher Effekt: statt einem Autostart-Skript gibt es bei mir einen fstab-Eintrag, der unter /mnt/ramdisk ein tmpfs anlegt. Ich wollte mal auf /tmp/ramdisk wechseln, aber erstens hätte ich dann eben solch einen Autostart gebraucht und zweitens hatte ich in dem Moment keine Lust, mein über Jahre gefestigtes Muskelgedächtnis zu ändern. Ferner habe ich dadurch das Hintergrundrauschen (die vielen kleinen tmpfiles laufender Prozesse) von meinen eigenen Nutzdaten klarer getrennt.

Inzwischen denke ich auch in 99 % der Fälle vor einem Runterfahren daran, nochmal in die Ramdisk zu gucken, ob sie noch zu sichernde Daten enthält.

 

[Caramon2]

Anderes Prinzip, gleicher Effekt: statt einem Autostart-Skript gibt es bei mir einen fstab-Eintrag, der unter /mnt/ramdisk ein tmpfs anlegt.

So in der Art hatte ich es auch mal, aber das wurden mir zu viele Einträge dort (da ich auch das Cache-Verzeichnis der Browser im RAM haben wollte, die Miniaturansichten sollten mir auch nicht die SSD immer weiter zumüllen, usw.

Also habe ich nur nur /tmp/ im RAM und erstelle dort per Autostart-Skript für alles benötigte ein Unterverzeichnis und leite es per Symlink dahin um.

Könnte mal übrigens auch mit /tmp/ramdisk/ so machen, um sich nicht ungewöhnlich zu müssen.

Der Vorteil des Skripts ist es: Man hat alles an einer Stelle und kann es problemlos auch für weitere Nutzer übernehmen/anpassen, wenn man ein Multiuser-System hat.

Das ist einfacher, als es für jeden einzelnen Nutzer (als Root) in die fstab zu packen.

 

[Caramon2]

Moin.

Den ersten Beitrag habe ich etwas überarbeitet, da ich inzwischen denke, dass es Quatsch ist, da zRAM-Swap-Größe je nach lz4/zstd auf 2/3 bzw. 3/4 zu begrenzen:

Die zRAM-Swap wird immer mit voller RAM-Größe erstellt (bei z. B. 6 GiB RAM mit 6 GiB) und belegt je nach Komprimierung entsprechend viel max. RAM:

• lz4 komprimiert üblicherweise 1:2, so das die zRAM-Swap max. ca. 3 GiB belegt
• das deutlich zstd komprimiert ca. 1:3, so dass max. 2 GiB belegt werden

(vorne habe ich das genauer erklärt)

Ich denke, bis einschl. 8 GiB RAM sollte man bei zRAM-Swap und -Disk zstd nutzen (besser langsamer, als out of memory) und darüber eben lz4.

Da tmpfs auch zum Thema gehört, habe ich einige "huge"-Optionen gebencht:

       huge=huge_option (since Linux 4.7.0)
              Set the huge table memory allocation policy for all files in this instance (if CONFIG_TRANSPARENT_HUGE_PAGECACHE is enabled).
              The huge_option value is one of the following:
              never  Do not allocate huge pages.  This is the default.
              always Attempt to allocate huge pages every time a new page is needed.
              advise Only allocate huge pages if requested with fadvise(2) or madvise(2).

Dabei war "always" am schnellsten (Bei mir zwar nur ca. 7,5%, aber praktisch für lau (Oder auch nicht! s. u.). Also wieso darauf verzichten?):

tmpfs /tmp tmpfs nosuid,huge=always,size=90% 0 0

(ich habe 32 GiB RAM, deshalb 90% - standardmäßig werden nur 50% genutzt)

Dabei ist wichtig, dass "huge=always" das nicht erzwingt, sondern nur nutzt, wenn genügend freier, zusammenhängender Speicher vorhanden ist. Ansonsten wird die normale Pagegröße genutzt, falls der freie Speicher zu fragmentiert ist.

Die Benches:

Ich habe auf einer SATA-SSD eine leere 8 GiB Partition erstellt und geblkdiscarded, die ich dann per "dd" und steigender Blockgröße (1M, 2M, 4M … 2G) ausgelesen habe, um davon die bestmögliche zu ermitteln.

Zuerst als Referenz nach /dev/null:

sync;sleep 1;dd if=/dev/sda5 iflag=direct of=/dev/null bs=1M;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=/dev/null bs=2M;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=/dev/null bs=4M;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=/dev/null bs=8M;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=/dev/null bs=16M;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=/dev/null bs=32M;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=/dev/null bs=64M;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=/dev/null bs=128M;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=/dev/null bs=256M;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=/dev/null bs=512M;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=/dev/null bs=1G;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=/dev/null bs=2G

8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 17,4986 s, 491 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 15,9816 s, 537 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 15,4872 s, 555 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 15,4221 s, 557 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 15,3025 s, 561 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 15,2945 s, 562 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 15,2355 s, 564 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 15,2626 s, 563 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 15,3232 s, 561 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 15,4364 s, 556 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 15,6926 s, 547 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 16,1789 s, 531 MB/s

Dann mit den Standardeinstellungen (huge=never) ins RAM:

cd /tmp/ramdisk/

sync;sleep 1;dd if=/dev/sda5 iflag=direct of=A bs=1M;rm A;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=A bs=2M;rm A;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=A bs=4M;rm A;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=A bs=8M;rm A;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=A bs=16M;rm A;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=A bs=32M;rm A;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=A bs=64M;rm A;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=A bs=128M;rm A;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=A bs=256M;rm A;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=A bs=512M;rm A;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=A bs=1G;rm A;sync;sleep 1;dd if=/dev/sda5 iflag=direct of=A bs=2G;rm A

8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 27,7050 s, 310 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 26,0631 s, 330 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,6126 s, 335 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,5688 s, 336 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,5455 s, 336 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,5446 s, 336 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,5551 s, 336 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,5147 s, 337 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,4740 s, 337 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,7499 s, 334 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,8322 s, 333 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 26,0938 s, 329 MB/s

Dto. mit "huge=always":

8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,7412 s, 334 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 24,0903 s, 357 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 23,9141 s, 359 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 23,9009 s, 359 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 23,8167 s, 361 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 23,8287 s, 360 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 23,7652 s, 361 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 23,8339 s, 360 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 23,8753 s, 360 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 23,9514 s, 359 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 24,1767 s, 355 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 24,7146 s, 348 MB/s

Und zuletzt mit "huge=advise", was überraschenderweise sogar etwas langsamer ist, als "huge=never":

8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 27,597 s, 311 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 26,3853 s, 326 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,8748 s, 332 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,7689 s, 333 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,6041 s, 335 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,6361 s, 335 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,6447 s, 335 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,7251 s, 334 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,8148 s, 333 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 25,9567 s, 331 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 26,0721 s, 329 MB/s
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 26,2305 s, 327 MB/s

 

[_roman_]

Hallo. Danke für den Tipp mittels huge=always, und den 50% bei tmpfs.

Ich werde das mal testen. Leider habe ich jetzt gerade keine Langzeitwerte, da ich gerade die Hardware ersetzt habe. downgraden will ich die Config files auch nicht.

Dimgrey Cavefish /home/roman # grep huge /etc/fstab
tmpfs            /var/tmp/portage        tmpfs    rw,nosuid,noatime,nodev,mode=775,uid=portage,gid=portage,x-mount.mkdir=775,huge=always    0 0
none                /tmp                                tmpfs    nofail,nodev,defaults,noatime,huge=always    0 0
none                /home/roman/Downloads                tmpfs    size=50%,noatime,nofail,huge=always                0 0

 

[Caramon2]

downgraden will ich die Config files auch nicht.

Ich hatte zuerst auch für jedes einen eigenen fstab-Eintrag, aber da mir das zu unübersichtlich und unflexibel wurde, habe ich jetzt nur noch /tmp/ im RAM und symlinke das andere dorthin.

Dazu habe ich mir eine "autostart.sh" geschrieben, die ich beim beim booten als normaler Nutzer ausführen lasse:

#!/bin/bash
mkdir -p /tmp/ramdisk
for v in mesa_shader_cache falkon opera thumbnails
do if [ -d ~/.cache/$v ]
then rm -rf ~/.cache/$v
fi
ln -s /tmp/.cache/$v ~/.cache/$v
mkdir -p /tmp/.cache/$v
done

/tmp/ramdisk habe ich beim Broswer einfach als Download-Ordner eingestellt und dafür im Dateimanager ein Lesezeichen eingerichtet.

 

[Caramon2]

Da tpmfs so lahm war, habe ich noch getestet, ob eine zRAM-Disk mit lz4 vielleicht sogar schneller wäre.

Standardmäßig formatiere ich die zRAM-Disk mit xfs, da ich damit (allgemein) schon seit 2017 die mit Abstand besten Erfahrungen gemacht habe (der aktuelle Kernel 6.3 Bug ist die bisher einzige Ausnahme).

Da Journaling im RAM eigentlich Quatsch ist und f2fs deshalb schneller sein müsste, habe ich das bei der Gelegenheit auch gleich getestet, wurde aber enttäuscht.

Auch ext4 und btrfs waren nicht schneller, wobei ext4 (wie üblich) die mit Abstand schlechteste Wahl war:

# sync;dd if=/dev/sda5 iflag=direct of=/tmp/zram1/A bs=64M;rm /tmp/zram1/A

xfs:
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 26,5852 s, 323 MB/s

f2fs:
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 28,0524 s, 306 MB/s

ext4:
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 38,1462 s, 225 MB/s

btrfs:
8589934592 Bytes (8,6 GB, 8,0 GiB) kopiert, 27,008 s, 318 MB/s

Ich habe jeweils mehrfach getestet: Obiges sind keine Ausreißer.

Bei btrfs zeigt zramctl den Mountpunkt aber nicht an:

NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram1 lz4            16G  4,4M 11,7K  164K       8

Ich dachte zuerst, es wäre nicht gemountet worden und habe die zRAM-Disk nochmal Schritt für Schritt erstellt (statt per angepassten "mkzram"-Skript), aber obwohl es keine Fehlermeldung gab und die zRAM-Disk definitiv in /tmp/zram1 gemountet war, wurde der Mountpunkt wieder nicht angezeigt.

Bei den anderen Dateisystemen (hier xfs) sah es dagegen so aus:

NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram1 lz4            16G  2,4M 56,2K  108K       8 /tmp/zram1

 

[Caramon2]

Danke für den Tipp mittels huge=always, und den 50% bei tmpfs.

Leider war das etwas voreilig, da ich das nur mit großen Dateien getestet habe, da es nur dabei auf die Geschwindigkeit ankommt. - Dachte ich…

Als ich neulich im Zuge eines Tests (ich wollte die Systempartition neu formatieren) meine Systempartition per rsync in die RAM-Disk kopiert habe, habe ich mich erschreckt, weil plötzlich mein RAM bis zum Anschlag voll war:

Die Systempartition enthält keine 8 GiB Daten: Wieso waren plötzlich die 32 GiB RAM randvoll !?

Zuerst dachte ich, etwas anders würde Mist machen, konnte aber nichts finden und nachdem ich die knapp 8 GiB gelöscht hatte, waren wieder die üblichen 30 GiB RAM frei. - Es konnte also nur an "huge=always" liegen.

Das habe ich dann so getestet (s. angehängtes Video *) ):

[linux ~]# gov s;cd /run/media/user/Artix-eSSD/;sync;tar c .|pv -s$(du -xsb|cut -f1) > /dev/null;sync;time rsync -axH ./ /tmp/ramdisk/Artix-eSSD/;echo -e "\n10 Sek. warten";sleep 10;rm -rf /tmp/ramdisk/Artix-eSSD;sync;tar c .|pv -s$(du -xsb|cut -f1) > /dev/null;sync;time tar cf /tmp/ramdisk/Artix-eSSD.tar .;echo -e "\n10 Sek. warten";sleep 10;rm /tmp/ramdisk/Artix-eSSD.tar;sync

*) 5 Min. FullHD ohne auffällige Qualitätsverluste auf unter 1 MiB encodet!

Zuerst setze ich die CPU mit meinem "gov"-Skript auf "powersave", damit die Taktwechsel nichts verfälschen und bei Idle-Takt Unterschiede sowieso auffälliger sind: Ich benche nicht als Schwanzvergleich.

Dann wird erst alles ins Nirvana kopiert, damit es im Datenträger-Cache ist und der Quelldatenträger "eigentlich" keine Rolle mehr spielt, aber da der Speicherverbrauch gleich sprunghaft ansteigt, wird der Datenträger-Cache schnell verdrängt, so dass schon nach ca. 30 Sek. doch von der ext. SSD gelesen werden muss und der Speicherverbrauch entsprechend langsamer ansteigt: s. Knick

Dann 10 Sek. Pause, damit man Zeit hat, das Video ggfs. anzuhalten.

Anschließend wird die Kopie gelöscht, der Inhalt erst wieder nach /dev/null kopiert, um ihn in den Datenträger-Cache zu bekommen und dann in ein unkomprimiertes .tar kopiert = eine große Daten = normaler Speicherverbrauch.

Hier die jeweilige Dauer:

7,65GiB 0:01:08 [ 113MiB/s] [=================================================================================================] 102%           

real    1m22,998s
user    0m18,289s
sys    1m17,439s

7,65GiB 0:01:06 [ 118MiB/s] [=================================================================================================] 102%           

real    0m20,573s
user    0m2,436s
sys    0m17,949s

Nachdem ich "huge=always" entfernt und rebootet habe, habe ich das wiederholt und diesmal war der Speicherverbrauch auch bei "rsync" normal (s. angehängten Screenshot).

Dadurch wurde der Datenträger-Cache auch nicht mehr verdrängt und es war fast doppelt so schnell (während tar nicht mehr von "huge=always" profitieren konnte):

7,65GiB 0:01:08 [ 114MiB/s] [=================================================================================================] 102%           

real    0m45,070s
user    0m16,790s
sys    0m51,051s

7,65GiB 0:00:17 [ 455MiB/s] [=================================================================================================] 102%           

real    0m23,734s
user    0m2,647s
sys    0m20,885s

Mein Fazit:

Für Große Dateien bringt "huge=always" einen Geschwindigkeitsvorteil, aber bei vielen kleinen Dateien wird der Speicherverbrauch absurd hoch: Die Systempartition enthält ca. 220000 Dateien, aber das RAM war ja schon viel früher am Anschlag!

Dann wurde wahrscheinlich auf normale Speicherseiten umgeschaltet und die dazwischen gequetscht: Es wurde ja weiter kopiert, aber trotzdem (zRAM-Swap und "swappiness=100") nichts ausgelagert.

Um die Systempartition zwischenzuspeichern kann ich natürlich eine zRAM-Disk einrichten, da ich das nicht oft mache, aber für jedes Mal, wenn ich viele kleine Dateien im RAM kurz zwischenlagern will, ist mir das zu aufwändig.

Für mich ist die Standardeinstellung (huge=never) deshalb das bedeutend kleinere Übel.

Nachtrag:

Ich bin so ein Idiot:

tmpfs       /tmp      tmpfs  nosuid,size=90%             0 0
tmpfs       /tmph     tmpfs  nosuid,huge=always,size=90% 0 0

 

[Caramon2]

Da ich dann doch noch darauf gekommen bin, dass ich beides parallel nutzen kann, lässt es sich leichter vergleichen:

gov s
dd if=/dev/zero of=t bs=1G count=8;time rm t

Beim erstellen der Datei ist "huge=always" knapp 12% schneller, aber beim löschen sogar fast 5000%:

tmph: 11,0 Sek. / 0,055 Sek.
tmp: 12,3 Sek. / 2,580 Sek.

Ich habe das mehrfach getestet und auch rebootet: Es variierte nur im ms-Bereich.

Bei einer VM-Installation ist "huge=always" dagegen sogar tendenziell langsamer:
(vermutlich aufgrund der 4k Sektoren und dem wahlfreien schreiben in der vHD - der Speicherbedarf der vHD blieb aber normal)

gov s
qemu-img create vHD.raw 40G
qemu-system-x86_64 -nodefaults -enable-kvm -cpu host -smp cores=4 -m 2G -display sdl,gl=on,window-close=off -vga virtio -drive file=artix.iso,if=virtio,aio=io_uring,snapshot=on,format=raw -drive file=vHD.raw,if=virtio,aio=io_uring,discard=unmap,format=raw

Jeweils frisch rebootet, alles vorbereitet, bei 4 Min. Uptime die VM gestartet und bei 5 Min. Uptime (des Hosts) die Installation.

Auch SimpleScreenRecorder (per Video kann ich die genaue Dauer ermitteln) nahm jeweils in die selbe RAM-Disk auf:

tmph: 2:20,2 Sek.
tmp: 2:19,1 Sek.

Das ist die reine Installationsdauer: Also genau vom Klick auf "Installieren" bis zum Frame mit dem "Alles erledigt." erscheint.

 

[hugo1337]

Vielleicht interessant: https://wiki.archlinux.org/title/Zram#Optimizing_swap_on_zram

Auf Arch wird auch standardmäßig /tmp/ in tmpfs umgeleitet:
https://wiki.archlinux.org/title/Tmpfs

Ich frage mich gerade noch ob es hierbei etwas in gleichzeitiger Verwendung mit LUKS2 zu beachten gibt.
Aber eigtl. ja nicht das alles ins RAM wandert und LUKS dort nichts verschlüsselt?
Somit auch keine Performance Probleme.

 

[Caramon2]

@hugo1337: Soweit ich weiß, ist LUKS bzgl. Swap nur relevant, wenn man die für den Ruhezustand nutzt: Ist due Home-Partition verschlüsselt, muss es auch die Swap sein (oder so - ich nutze den Ruhezustand nicht).

Da es keinen Sinn macht, den Ruhezustand in einer RAM-Disk zu speichern, sollte das keinen Einfluss haben.

Ach ja: Man könnte natürlich einen LUKE-Container in einer zRAM-Disk erstellen, um sie zu verschlüsselt, aber das wäre kontraproduktiv, da sich der verschlüsselte Inhalt natürlich nicht mehr komprimieren lässt.

 

[hugo1337]

Hm mein Gedanke war das RAM bzw. ZRAM bzw. damit auch den Ruhezustand gar nicht zu verschlüsseln.

1. Aufgrund der evtl. Performance Probleme und
2. weil ich nicht davon ausgehe, dass der 0815 Dieb/Findling von meinem Laptop die Fähigkeiten besitzt um dass aus dem RAM auszulesen und zu entschlüsseln. Sobald einmal der Strom weg ist oder ein Neustart durchgeführt wird, ist das System sowieso auch wieder zu 100% verschlüsselt.

 

[Caramon2]

Ruhezustand heißt für mich "Suspend to Disk": Dann ist der Strom aus und das RAM gelöscht. - Aber wie gesagt, den nutze ich nicht.

Mir reicht es, dass meine Home-Partition per LUKS verschlüsselt ist und nichts sensibles auf der unverschüsselten Linux-Partition geschrieben wird: /tmp ist im RAM, mlocate (oder vergleichbares) ist nicht installiert und eine Swap-Datei/-Partition habe ich nicht, sondern die zRAM-Swap.

Wenn ich den Rechner mit Win+L abschließe, kann man ihn zwar per Hardreset rebooten, aber spätestens bei der Passwort zum entsperren der Home-Partition geht es nicht mehr weiter. - Auch von einem Livesystem kommt man nicht daran.

 

[hugo1337]

Oh da haben wir aneinander vorbei geredet:
Ich meinte mit "Ruhezustand" den "Standby" d.h. "Suspend to Ram".

Über eine Verschlüsselung von nur "/root/" und "/home/" habe ich auch schon nachgedacht.
Das würde mir eigtl. auch schon reichen und sollte die Performance nochmal ein Stück verbessern.
Ich meine irgendwo mal gelesen zu haben, dass man nachträglich die LUKS Verschlüsselung entfernen kann. Bin mir dann nur nicht sicher ob ich einfach so den bestehenden "/home/" wieder verschlüsseln kann.

Wobei für die Verschlüsselung von "nur" /home/" laut dem Archwiki eher eCryptfts empfohlen wird anstatt von LUKS?

 

[Donnerkind]

Über eine Verschlüsselung von nur "/root/" und "/home/" habe ich auch schon nachgedacht.

Ich habe auf meinem PC und Laptop eine Vollverschlüsselung eingerichtet. Das schien mir weniger aufwändig und vor allem flexibler für später: Partition → LUKS → LVM. Das hat mir auch schonmal den Popo gerettet, denn meine root-Partition wurde zu eng und so konnte ich ganz einfach etwas von der Datenpartition abzwacken – ganz ohne Sicherung der Daten und Neuverschlüsselung. Außerdem sind so eventuell vorhandene Swap-Dateien gleich mit verschlüsselt (nur suspend-to-disk geht mit ihnen nicht, aber das benutze ich ebenfalls nicht).

Wobei für die Verschlüsselung von "nur" /home/" laut dem Archwiki eher eCryptfts empfohlen wird anstatt von LUKS?

Auf meinem Tablet sieht das anders aus, dort wollte ich die Passworteingabe vom frühen Boot in den grafischen Teil verschieben, damit das im Notfall (wenn die Tastatur nicht angesteckt ist) auch per Touch funktioniert. Deshalb ist root unverschlüsselt und ich habe mich für LUKS mit pam_mount entschieden. ecryptfs war mir mit zuviel Overhead verbunden, gerade bei dem lahmen 4415Y und der langsamen SSD, die in dem Surface stecken.

 

[hugo1337]

Ja genau das stört mich auch ein bisschen.
Für LUKS muss /home/ eine eigene Partition sein. D.h. eine fix gebundene Größe für /home/ und damit auch das restliche system.

 

[Donnerkind]

Je nun, ich habe aus Robustheitsgründen /home von Anbeginn auf einer separaten Partition. Und mit LVM ist man ja tatsächlich flexibler, weil man nach Belieben Platz hin und her schieben kann ohne statische Partitionen anfassen zu müssen. Die einzige Voraussetzung ist, dass die Dateisysteme die entsprechenden Aktionen unterstützen. f2fs kann z.B. nur vergrößert, aber nicht verkleinert werden.

 

[hugo1337]

Hm dass man dem hin und her schieben mit LVM habe ich nicht ganz verstanden.
Man erzeugt ja quasi einen großen verschlüsselten LUKS Block.
In diesem gibt es dann ein oder mehrere LVM's. Diese kann man nach belieben schieben aber am ende ich ja trotzdem alles in diesem einem verschlüsselten LUKS Block?

Was ich bräuchte, wäre eine Möglichkeit um /home/ nach belieben in der größere zu verändern und dabei aber immer als LUKS verschlüsselt zu sein.

Edit:
Wobei man scheinbar nachträglich einen LUKS Block auch noch vergrößern / verkleinern kann. Das wäre im notfall auch eine Lösung:
https://wiki.archlinux.org/title/Resizing_LVM-on-LUKS