Stellen Sie sich vor: Sie haben eine nagelneue, blitzschnelle NVMe-SSD, eine der besten ihrer Klasse, und installieren darauf das neueste Ubuntu LTS – die vermeintlich stabile und leistungsstarke Linux-Distribution. Was Sie erwarten, ist ein System, das nur so flitzt, Anwendungen in Millisekunden startet und Dateitransfers in Rekordzeit abschließt. Doch dann die Ernüchterung: Ihr System kriecht förmlich. Bootvorgänge ziehen sich in die Länge, Programme starten nur zögerlich, und selbst einfache Dateioperationen fühlen sich an wie eine Ewigkeit. Genau dieses Szenario berichten erschreckend viele Nutzer, die versucht haben, **Ubuntu 24.04.1 LTS** auf einer 1TB Lexar NM790 zu installieren. Eine High-End-SSD, die in Benchmarks brilliert, wird unter Linux zum Flaschenhals. Aber warum? Was steckt hinter dieser rätselhaften **Performance-Bremse**? Tauchen wir ein in die Tiefen des Pinguin-Systems und entschlüsseln dieses Phänomen.
### Die Protagonisten: Ubuntu 24.04.1 LTS und die Lexar NM790
Bevor wir die Ursachen ergründen, werfen wir einen genaueren Blick auf unsere beiden Protagonisten. Die **Lexar NM790** ist eine bemerkenswerte NVMe-SSD der PCIe Gen4-Klasse, die mit beeindruckenden Lese- und Schreibraten von bis zu 7400 MB/s bzw. 6500 MB/s wirbt. Ihr Geheimnis? Sie ist eine sogenannte **DRAM-less SSD**, die anstelle eines dedizierten DRAM-Cache den Host Memory Buffer (HMB) nutzt. HMB erlaubt es der SSD, einen Teil des Systemspeichers (RAM) als Cache zu verwenden, um die Leistung zu steigern, ohne die Kosten und Komplexität eines physischen DRAM-Chips tragen zu müssen. In vielen Windows-Systemen und Benchmarks schneidet die NM790 hervorragend ab und bietet ein herausragendes Preis-Leistungs-Verhältnis.
Auf der anderen Seite haben wir **Ubuntu 24.04.1 LTS**, Codename „Noble Numbat”. Als Long Term Support (LTS)-Version verspricht sie fünf Jahre Stabilität und Sicherheit, was sie zur bevorzugten Wahl für viele Anwender macht, die ein zuverlässiges System suchen. Sie basiert auf dem neuesten **Linux-Kernel 6.8**, bringt GNOME 46 mit sich und verspricht diverse Leistungsoptimierungen und verbesserte Hardware-Unterstützung. Man sollte meinen, dass die Kombination aus modernster Linux-Distribution und einer Spitzen-SSD ein Traumpaar darstellt. Doch die Realität sieht oft anders aus.
### Die „Pinguin-Bremse” – Symptome und Beobachtungen
Die Berichte über die Trägheit sind vielfältig, aber die Kernsymptome sind konsistent:
* **Lange Bootzeiten**: Statt weniger Sekunden dauert der Startvorgang oft eine halbe Minute oder länger.
* **Verzögerte Anwendungsstarts**: Programme wie Firefox, LibreOffice oder der Dateimanager brauchen spürbar länger zum Laden.
* **Langsame Dateioperationen**: Kopieren, Verschieben oder Entpacken großer Dateien dauert unverhältnismäßig lange.
* **Allgemeine Systemträgheit**: Selbst das Öffnen von Menüs oder das Wechseln zwischen Anwendungen fühlt sich schleppend an.
* **Hohe I/O-Latenz**: Tools wie `iotop` zeigen hohe Latenzzeiten und geringen Durchsatz, obwohl die CPU nicht ausgelastet ist.
Diese Symptome deuten auf ein grundlegendes Problem im Bereich der **Datenträger-E/A (Input/Output)** hin. Es scheint, als würde die SSD nicht annähernd ihre beworbene Leistung erreichen, was zu einer **systemweiten Performance-Bremse** führt.
### Anatomie eines Rätsels: Mögliche Ursachenforschung
Die Suche nach der Ursache dieser Performance-Probleme ist komplex und führt uns durch verschiedene Schichten der Systemarchitektur.
#### Die „DRAM-less” Falle: HMB und seine Tücken unter Linux
Hier liegt oft der erste und wichtigste Verdacht. Während **Host Memory Buffer (HMB)** unter Windows dank ausgereifter Treiber und einer engen Integration in das Betriebssystem hervorragend funktioniert, kann die Situation unter Linux komplexer sein. Linux-Distributionen müssen die HMB-Funktionalität korrekt erkennen und effizient nutzen. Wenn der Kernel oder der NVMe-Treiber die HMB-Funktionalität nicht optimal implementieren oder gar nicht unterstützen, greift die SSD auf einen internen, viel kleineren Cache zurück oder muss häufiger direkten Zugriff auf den NAND-Speicher vornehmen, was deutlich langsamer ist. Dies kann sich in hohen Latenzen und einer drastisch reduzierten Schreibleistung manifestieren, insbesondere bei kleinen, zufälligen Schreibzugriffen, die für ein Betriebssystem typisch sind. Der Phison E21T Controller, der in der Lexar NM790 verbaut ist, ist auf HMB angewiesen, um seine volle Leistung zu entfalten.
#### Linux-Kernel 6.8: Eine Ursache für Kompatibilitätsprobleme?
Jeder neue Kernel bringt Verbesserungen, aber manchmal auch Regressionen oder Kompatibilitätsprobleme mit spezifischer Hardware. Der **Linux-Kernel 6.8** mag mit bestimmten NVMe-Controllern, wie dem Phison E21T, Schwierigkeiten haben, die **HMB-Implementierung** korrekt zu handhaben. Es könnte sein, dass der NVMe-Treiber im Kernel nicht vollständig für diesen Controller optimiert ist oder es Probleme mit der Stromversorgung (Power Management) oder den PCIe-Link-States gibt, die die SSD in einen ineffizienten Zustand versetzen. Solche Feinheiten können massive Auswirkungen auf die **Systemleistung** haben.
#### Dateisystem und Mount-Optionen: Ext4 am Pranger?
Standardmäßig verwendet Ubuntu das **ext4-Dateisystem**. Während ext4 im Allgemeinen sehr robust und leistungsfähig ist, können bestimmte Mount-Optionen oder Journaling-Einstellungen die Performance beeinflussen.
* **Journaling**: Die Standardeinstellung `data=ordered` sichert zwar die Datenintegrität, erzeugt aber bei vielen kleinen Schreibvorgängen zusätzlichen Overhead.
* **Noatime/relatime**: Die Option `atime` (Access Time) aktualisiert jedes Mal, wenn eine Datei gelesen wird, deren Zugriffszeit. `noatime` oder `relatime` (die Standardeinstellung auf modernen Systemen) reduzieren diese Schreibvorgänge, was die Performance leicht verbessern kann.
* **Discard/fstrim**: TRIM-Befehle sind entscheidend für die langfristige Performance von SSDs, da sie dem Controller mitteilen, welche Blöcke gelöscht werden können. `discard` als Mount-Option führt TRIM sofort aus, was bei vielen kleinen Löschvorgängen zu Latenzen führen kann. Eine periodische Ausführung von `fstrim` (was die Standardeinstellung ist) ist oft effizienter. Ein Problem mit der korrekten Ausführung des Befehls könnte zu einer langsamen Degradation der Leistung führen.
#### Power Management: Die Sparflamme zu heiß gekocht
Linux ist bekannt für seine detaillierten Power-Management-Fähigkeiten. Manchmal können diese jedoch zu aggressiv sein, insbesondere bei neuerer Hardware.
* **PCIe Active State Power Management (ASPM)**: Wenn ASPM zu aggressiv eingestellt ist, kann die PCIe-Verbindung zur SSD häufig in einen Energiesparmodus wechseln und für jeden Zugriff erst wieder aufwachen. Das spart zwar Energie, führt aber zu erhöhten Latenzen.
* **NVMe Power States**: Auch die SSD selbst verfügt über verschiedene Stromsparstufen. Eine falsche Konfiguration oder ein Treiberproblem könnte die SSD zwingen, ineffiziente oder zu tiefe Stromsparstufen zu verwenden, aus denen sie nur langsam erwacht.
#### BIOS/UEFI und Firmware: Die Basis des Problems
Die Basis für die reibungslose Kommunikation zwischen Hardware und Betriebssystem bilden das BIOS/UEFI und die SSD-Firmware.
* **Veraltetes BIOS/UEFI**: Ein veraltetes Mainboard-BIOS/UEFI könnte die PCIe Gen4-Spezifikationen oder die spezifische Implementierung des NVMe-Controllers der Lexar NM790 nicht optimal unterstützen. BIOS-Updates enthalten oft Verbesserungen für NVMe-Kompatibilität und Stabilität.
* **SSD-Firmware**: Auch die Firmware der Lexar NM790 selbst kann Fehler enthalten oder spezifische Optimierungen für Linux benötigen, die in älteren Versionen noch nicht vorhanden sind. Leider ist das Aktualisieren der Firmware von Lexar-SSDs unter Linux oft schwierig oder gar nicht vorgesehen, was die Problemanhebung erschwert.
#### I/O-Scheduler: Der Dirigent der Datenströme
Der Linux **I/O-Scheduler** entscheidet, in welcher Reihenfolge und mit welcher Priorität Lese- und Schreibanfragen an die Speichergeräte gesendet werden. Für SSDs ist der **`mq-deadline`** oder sogar **`none` (noop)** Scheduler oft die beste Wahl, da SSDs keine mechanischen Kopfbewegungen haben, die optimiert werden müssten. Wenn ein weniger geeigneter Scheduler wie `bfq` (der für HDDs optimiert ist) aktiv ist oder der Scheduler nicht optimal mit der HMB-Funktionalität des Controllers harmoniert, kann dies die Performance beeinträchtigen.
#### Snap Packages: Ein Faktor, aber selten die Hauptursache für *systemweite* Langsamkeit
Obwohl **Snap-Pakete** bekanntermaßen beim ersten Start länger brauchen, da sie in Containern ausgeführt werden und zusätzliche Mounts benötigen, erklären sie nicht die **systemweite Trägheit** des Dateisystems oder die langen Bootzeiten. Sie können zur allgemeinen Frustration beitragen, sind aber für dieses fundamentale Problem selten die Hauptursache.
### Diagnose und Erste Hilfe: Was kann man tun?
Die Fehlersuche bei solchen Problemen erfordert Geduld und systematisches Vorgehen. Hier sind Schritte, die Sie unternehmen können:
1. **BIOS/UEFI und SSD-Firmware aktualisieren**: Stellen Sie sicher, dass Ihr Mainboard das neueste BIOS/UEFI und Ihre Lexar NM790 die aktuellste Firmware besitzt. Für die SSD-Firmware kann es notwendig sein, dies unter Windows durchzuführen, falls Lexar kein Linux-Tool anbietet.
2. **Kernel-Updates verfolgen**: Überprüfen Sie regelmäßig, ob neuere Kernel-Versionen für Ubuntu 24.04.1 verfügbar sind. Spezifische Treiberprobleme oder HMB-Optimierungen werden oft in späteren Kernel-Updates behoben.
3. **Mount-Optionen anpassen**: Überprüfen Sie Ihre `/etc/fstab` für die SSD-Partition. Stellen Sie sicher, dass `relatime` (Standard) oder `noatime` verwendet wird. Entfernen Sie die `discard`-Option und verlassen Sie sich auf den `fstrim`-Dienst, der periodisch im Hintergrund läuft (standardmäßig aktiviert).
4. **I/O-Scheduler überprüfen und anpassen**: Finden Sie den aktuellen Scheduler für Ihre NVMe-SSD: `cat /sys/block/nvme0n1/queue/scheduler`. Für NVMe-SSDs ist `mq-deadline` oft die beste Wahl. Sie können dies temporär testen und bei Erfolg dauerhaft über Kernel-Parameter in GRUB einstellen.
5. **Power Management Einstellungen anpassen**: Deaktivieren Sie testweise ASPM (PCIe Link State Power Management) im BIOS/UEFI, falls verfügbar. Im Kernel können fortgeschrittene Nutzer versuchen, `nvme_core.default_ps_max_latency_us` Parameter anzupassen, um aggressive Stromsparstufen zu reduzieren.
6. **Leistungsüberwachungstools nutzen**: Verwenden Sie `iotop` für Prozess-I/O, `iostat -xz 1` für detaillierte Lese-/Schreibleistung und Latenzen, sowie `smartctl -a /dev/nvme0n1` und `nvme smart-log /dev/nvme0n1` zur Überprüfung der SSD-Gesundheit und Fehlerprotokolle.
7. **Testen mit Live-Distributionen oder einer anderen Linux-Version**: Probieren Sie einen Live-USB-Stick mit einer anderen Distribution (z.B. Fedora, Arch Linux) oder einer älteren Ubuntu-Version aus, um festzustellen, ob das Problem spezifisch für Ubuntu 24.04.1 oder den Kernel 6.8 ist.
8. **Community und Bugtracker**: Suchen Sie in Foren und Bugtrackern nach ähnlichen Berichten und erwägen Sie, selbst einen detaillierten Bugreport zu erstellen, um auf das Problem aufmerksam zu machen.
### Die Langzeitperspektive: Ein Ausblick
Probleme mit der **Performance von NVMe-SSDs**, insbesondere solchen, die auf HMB setzen, sind unter Linux nicht neu. Die Linux-Entwickler arbeiten kontinuierlich daran, die Unterstützung für neue Hardware und Technologien zu verbessern. Oft sind es spezifische Kernel-Versionen, die nicht optimal mit bestimmten Controller-Firmwares zusammenarbeiten, und diese Probleme werden in späteren Updates behoben. Die Rolle der Community ist hier entscheidend: Je mehr Nutzer solche Probleme melden und detaillierte Informationen bereitstellen, desto schneller können Lösungen gefunden und in den Kernel oder die Distribution integriert werden.
Es ist denkbar, dass künftige Kernel-Updates für Ubuntu 24.04.1 LTS oder sogar ein späteres Point-Release (z.B. 24.04.2) die notwendigen Optimierungen oder Fehlerbehebungen mitbringen, um die **Lexar NM790** und ähnliche DRAM-less SSDs optimal zu unterstützen. Bis dahin ist es eine Aufgabe für die Anwender, die genannten Diagnose- und Lösungsansätze zu nutzen, um die bestmögliche Leistung aus ihrer Hardware herauszuholen.
### Fazit
Das Phänomen der extrem langsamen **Ubuntu 24.04.1 LTS** auf einer 1TB Lexar NM790 ist ein Paradebeispiel dafür, wie komplex das Zusammenspiel von Hardware, Firmware und Betriebssystem sein kann. Was auf dem Papier wie eine perfekte Kombination erscheint, kann in der Praxis zu erheblichen Frustrationen führen. Die wahrscheinlichsten Ursachen liegen in der suboptimalen Handhabung der **DRAM-less HMB-Technologie** der SSD durch den **Linux-Kernel 6.8** oder dessen NVMe-Treiber, gepaart mit möglichen Problemen in den Power-Management-Einstellungen oder dem I/O-Scheduler.
Es ist eine Herausforderung, die sowohl die Hersteller (für bessere Linux-Kompatibilität der Firmware) als auch die Open-Source-Community (für optimierte Kernel-Treiber) angeht. Für den Endnutzer bedeutet dies im Moment, geduldig die genannten Schritte zur Fehlersuche und Optimierung zu durchlaufen. Die gute Nachricht ist, dass solche Probleme in der Linux-Welt selten von Dauer sind. Mit jedem Update wächst die Kompatibilität, und die **Performance-Bremse** wird hoffentlich bald vollständig gelöst sein, sodass die **Lexar NM790** auch unter dem Pinguin-System ihre volle Geschwindigkeit entfalten kann. Bis dahin bleibt es eine Detektivarbeit, die uns tief in die Eingeweide des Systems blicken lässt.