Mein openSUSE Leap 15.0 starte ich momentan in etwa 1.3s laut systemd-analyze. Unter gleichem Nutzernamen wie hier habe ich im openSUSE-Forum öfters mal aufgelistet, was ich dafür getan habe: in der Hauptsache eine schnelle SSD mit einer großen, korrekt ausgerichteten ext4-Partition verwendet, Unnötiges aus dem Bootprozess entfernt, kdm ohne Themes verwenet, und so weiter.
(Details siehe Thread »537299-Extremely-slow-boot-for-new-tumbleweed-gnome-installation« im openSUSE-Forum).
Mein bestes Ergebnis war ein Warmstart (Reboot) in 1.211 Sekunden. Heute früh wars nicht so schnell, der Kaltstart dauerte 1.339s.
Mit einem Partitionseditor wie GParted etc. solltest Du für den Startblock der Partition eine Blocknummer wählen, die durch 2048 teilbar ist.
SSDs brauchen ja auch immer ein bisschen Platz für Wear-Leveling und andere interne Wartungsaktivitäten, da kann man ruhig etwas »Luft« zwischen den Partitionen lassen. Alternativ kann man auch eine Swap-Partition dazupacken, die selten oder nur zu einem kleinen Teil von Linux genutzt wird.
Noch ein Trick: ich dachte anfangs, dass der »noop«-Scheduler ideal für SSDs ist — nein, »deadline« scheint noch ein paar Kniffe anzuwenden, damit SSDs schneller arbeiten können. Ein anderer Parameter wäre dann noch »swappiness«, aber ich denke, das hilft nur dann, wenn oft das RAM knapp wird.
Ja, Verschlüsselung mache ich nur bei ein paar wenigen Dateien. Für SSD-Verschlüsselung sind mir meine CPU-Zyklen zu kostbar. Das könnte sich aber ändern, sobald die Verschlüsselung in Hardware und »nahe« an oder in den SSDs stattfindet.
Hardwareverschlüsselung seitens der SSH ist nicht sicher. Besonders wenn man auch deshalb verschlüsselt, um bei einem Defekt die Garantie der SSD in Anspruch nehmen zu können, ist dies keine Option.
Allerdings kann man die Hardwareunterstützung der CPU nutzen, Stichwort AES-NI. Damit und einer Multicore-CPU ist die Verschlüsselung im Normalbetrieb eigentlich nicht wahrnehmbar. Nur die Verzögerung beim Booten merkt man eben, da entsperren Zeit kosten muss um die Anzahl der Versuche zu limitieren. Außerdem wartet man alleine schon 2 Sekunden auf das USB-Backend, um einen Key von USB einlesen zu können. D.h. in der Zeit hast du schon durchgebootet. Irgend einen Tod muss man leider sterben.
Gute Argumente. Seit Snowden und der Einmischung der US-Regierung in von ANSI und NIST vorgeschlagenen Standards ist auch möglich, dass Hersteller von Verschlüsselungstechnologie gezwungen werden, kryptografische Hintertüren einzubauen, aber ohne dies publik machen zu dürfen.
Meine generelle Sorge bei der Verschlüsselung ganzer Partitionen oder Platten sind Defekte. Während bei Lesefehlern in unverschlüsselten Bereichen oft eine Rettung der meisten Blöcke möglich ist (sogar eine heuristische »Schätzung« der defekten Bits seitens der Platten-Firmware und dd), kann bei Block-Level-Verschlüsselung im Extremfall ein falsches Bit dazu führen, dass gar nix mehr lesbar ist, ähnlich wie bei proprietärer und zu »cleverer« RAID-Hardware, wo im Fehlerfall uninterpretierbarer Bit-Salat übrig bleibt.
Da bleibe ich lieber noch eine Weile bei Dateiverschlüsselung der paar Files, die mir echt wichtig sind. Das meiste auf der Platte sind in meinem Fall Steam-Spiele und die Standardinstallation aus openSUSE-Paketen — kein Anlass hier zum Verschlüsseln, nur zum gelegentlichen Verifizieren der Checksummen. Zusammen mit bewährten Dateisystemen (ext4, XFS) und robusten Backup-Strategien sollte das doch für fast alle Fälle ausreichen.
Ich war mal ein Jahr als Externer bei der Datev eG in Nürnberg, wo generell alle mobilen Geräte verschlüsselt sein müssen, habe ab und zu mitbekommen, was da alles schief geht und davon gelernt — aber wie Du schon so treffend schriebst: »Irgend einen Tod muss man leider sterben.«
Da bin ich ganz bei dir, Verschlüsselung erhöht die Komplexität, was immer dann wenn es darauf ankommt, Abläufe teils massiv verkompliziert oder gar unmöglich macht. Wer schon einmal eine Festplatte hatte, welche langsam anfing unkorrigierbare Blöcke zu melden (bekommt man dank SMART-Monitoring rechtzeitig mit, kann ich nur empfehlen), der wird zu schätzen wissen, wenn er über Low-Level Tools feststellen kann, in welchen Dateien sich die defekten Blöcke befinden, um diese gezielt ersetzen zu können. Da kann jeder weitere Layer an Komplexität schnell einer zu viel sein.
Andererseits dürften moderne SSDs ein ganz anderes Fehlerverhalten haben und ein gutes Backup ist ohnehin durch nichts zu ersetzen. Im Problemfall wird einem die höhere Komplexität aber sicherlich nicht von Vorteil sein.
Mein openSUSE Leap 15.0 starte ich momentan in etwa 1.3s laut systemd-analyze. Unter gleichem Nutzernamen wie hier habe ich im openSUSE-Forum öfters mal aufgelistet, was ich dafür getan habe: in der Hauptsache eine schnelle SSD mit einer großen, korrekt ausgerichteten ext4-Partition verwendet, Unnötiges aus dem Bootprozess entfernt, kdm ohne Themes verwenet, und so weiter.
(Details siehe Thread »537299-Extremely-slow-boot-for-new-tumbleweed-gnome-installation« im openSUSE-Forum).
Mein bestes Ergebnis war ein Warmstart (Reboot) in 1.211 Sekunden. Heute früh wars nicht so schnell, der Kaltstart dauerte 1.339s.
Wie richtest Du ein partition auf einer ssd richtig aus?
Mit einem Partitionseditor wie GParted etc. solltest Du für den Startblock der Partition eine Blocknummer wählen, die durch 2048 teilbar ist.
SSDs brauchen ja auch immer ein bisschen Platz für Wear-Leveling und andere interne Wartungsaktivitäten, da kann man ruhig etwas »Luft« zwischen den Partitionen lassen. Alternativ kann man auch eine Swap-Partition dazupacken, die selten oder nur zu einem kleinen Teil von Linux genutzt wird.
Noch ein Trick: ich dachte anfangs, dass der »noop«-Scheduler ideal für SSDs ist — nein, »deadline« scheint noch ein paar Kniffe anzuwenden, damit SSDs schneller arbeiten können. Ein anderer Parameter wäre dann noch »swappiness«, aber ich denke, das hilft nur dann, wenn oft das RAM knapp wird.
Haha, alleine die SSD-Verschlüsselung braucht hier schon 6 Sekunden, während dieser Zeit hast du schon 4x dein System gebootet
Ja, Verschlüsselung mache ich nur bei ein paar wenigen Dateien. Für SSD-Verschlüsselung sind mir meine CPU-Zyklen zu kostbar. Das könnte sich aber ändern, sobald die Verschlüsselung in Hardware und »nahe« an oder in den SSDs stattfindet.
Mein Boot von heute morgen laut »systemd-analyze blame«:
~ ▶ systemd-analyze
Startup finished in 231ms (kernel) + 712ms (initrd) + 387ms (userspace) = 1.331s
~ ▶ systemd-analyze blame
114ms udisks2.service
102ms systemd-journal-flush.service
97ms polkit.service
85ms display-manager.service
76ms systemd-udevd.service
62ms upower.service
43ms klog.service
30ms systemd-udev-trigger.service
27ms systemd-tmpfiles-setup.service
22ms user@1000.service
22ms systemd-remount-fs.service
21ms sys-kernel-debug.mount
18ms dev-mqueue.mount
18ms dev-hugepages.mount
16ms systemd-modules-load.service
15ms systemd-logind.service
15ms systemd-tmpfiles-setup-dev.service
13ms systemd-networkd.service
11ms systemd-fsck-root.service
11ms systemd-update-utmp.service
10ms systemd-sysctl.service
8ms systemd-journald.service
6ms dracut-shutdown.service
5ms systemd-random-seed.service
5ms kmod-static-nodes.service
3ms rtkit-daemon.service
3ms systemd-update-utmp-runlevel.service
2ms systemd-user-sessions.service
1ms systemd-vconsole-setup.service
~ ▶ _
Hardwareverschlüsselung seitens der SSH ist nicht sicher. Besonders wenn man auch deshalb verschlüsselt, um bei einem Defekt die Garantie der SSD in Anspruch nehmen zu können, ist dies keine Option.
Allerdings kann man die Hardwareunterstützung der CPU nutzen, Stichwort AES-NI. Damit und einer Multicore-CPU ist die Verschlüsselung im Normalbetrieb eigentlich nicht wahrnehmbar. Nur die Verzögerung beim Booten merkt man eben, da entsperren Zeit kosten muss um die Anzahl der Versuche zu limitieren. Außerdem wartet man alleine schon 2 Sekunden auf das USB-Backend, um einen Key von USB einlesen zu können. D.h. in der Zeit hast du schon durchgebootet. Irgend einen Tod muss man leider sterben.
Gute Argumente. Seit Snowden und der Einmischung der US-Regierung in von ANSI und NIST vorgeschlagenen Standards ist auch möglich, dass Hersteller von Verschlüsselungstechnologie gezwungen werden, kryptografische Hintertüren einzubauen, aber ohne dies publik machen zu dürfen.
Meine generelle Sorge bei der Verschlüsselung ganzer Partitionen oder Platten sind Defekte. Während bei Lesefehlern in unverschlüsselten Bereichen oft eine Rettung der meisten Blöcke möglich ist (sogar eine heuristische »Schätzung« der defekten Bits seitens der Platten-Firmware und dd), kann bei Block-Level-Verschlüsselung im Extremfall ein falsches Bit dazu führen, dass gar nix mehr lesbar ist, ähnlich wie bei proprietärer und zu »cleverer« RAID-Hardware, wo im Fehlerfall uninterpretierbarer Bit-Salat übrig bleibt.
Da bleibe ich lieber noch eine Weile bei Dateiverschlüsselung der paar Files, die mir echt wichtig sind. Das meiste auf der Platte sind in meinem Fall Steam-Spiele und die Standardinstallation aus openSUSE-Paketen — kein Anlass hier zum Verschlüsseln, nur zum gelegentlichen Verifizieren der Checksummen. Zusammen mit bewährten Dateisystemen (ext4, XFS) und robusten Backup-Strategien sollte das doch für fast alle Fälle ausreichen.
Ich war mal ein Jahr als Externer bei der Datev eG in Nürnberg, wo generell alle mobilen Geräte verschlüsselt sein müssen, habe ab und zu mitbekommen, was da alles schief geht und davon gelernt — aber wie Du schon so treffend schriebst: »Irgend einen Tod muss man leider sterben.«
Da bin ich ganz bei dir, Verschlüsselung erhöht die Komplexität, was immer dann wenn es darauf ankommt, Abläufe teils massiv verkompliziert oder gar unmöglich macht. Wer schon einmal eine Festplatte hatte, welche langsam anfing unkorrigierbare Blöcke zu melden (bekommt man dank SMART-Monitoring rechtzeitig mit, kann ich nur empfehlen), der wird zu schätzen wissen, wenn er über Low-Level Tools feststellen kann, in welchen Dateien sich die defekten Blöcke befinden, um diese gezielt ersetzen zu können. Da kann jeder weitere Layer an Komplexität schnell einer zu viel sein.
Andererseits dürften moderne SSDs ein ganz anderes Fehlerverhalten haben und ein gutes Backup ist ohnehin durch nichts zu ersetzen. Im Problemfall wird einem die höhere Komplexität aber sicherlich nicht von Vorteil sein.