Der stärkste Beleg in diesem Quellthread ist nicht der Screenshot mit 600 MB/s bei Files, sondern der spätere Direktzugriffstest. Ein Nutzer, dessen Kopiervorgang in der ZimaOS-WebUI bei etwa 600–650 MB/s blieb, maß mit dd direkte Schreibvorgänge von ungefähr 2,3 GB/s und mit fio etwa 2,2 GB/s. Damit ist für dieses System eine Erklärung ausgeschlossen, nach der NVMe systemweit auf SATA III begrenzt ist.
Die belastbarere Schlussfolgerung ist, dass der niedrige Wert zum internen Files-Kopierworkflow oder zu Effekten des Kopiervorgangs gehörte, etwa Metadaten, Btrfs-CoW, Pufferung oder Einschränkungen durch einen einzelnen Thread – nicht zum physischen NVMe-Pfad selbst.
Die Quelle reproduzierte die Begrenzung über mehrere Kopierpfade hinweg
Dave berichtete von einem ähnlichen Verhalten bei NVMe-zu-NVMe, NVMe-zu-RAID0, RAID0-zu-einer einzelnen NVMe und 10-GbE-Workflows. Ein anderer Nutzer erklärte später, dass SMB-Kopien von Windows zu ZimaOS die volle 10-GbE-Geschwindigkeit erreichten, während interne Kopiervorgänge in Files weiterhin bei etwa 650 MB/s blieben.
Direkte dd-Schreibvorgänge erreichten etwa 2,3 GB/s
Die Quelle verwendete dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progress und veröffentlichte ein Ergebnis von knapp 2,3 GB/s – deutlich über dem praktisch erreichbaren Datendurchsatz von SATA III.
Auch fio erreichte etwa 2,2 GB/s
Der fio-Lauf der Quelle meldete Schreibwerte von ungefähr 2163 MiB/s beziehungsweise 2268 MB/s. Obwohl die gewählte synchrone Engine die Warteschlangentiefe effektiv auf eins begrenzte, bewies das Ergebnis dennoch, dass der Speicher-Stack den Files-Kopierwert um ein Mehrfaches übertreffen konnte.
Den von dd gemessenen Lesewert der Quelle mit Vorsicht bewerten
Die Quelle maß außerdem beim Lesen der gerade geschriebenen Testdatei nach /dev/null etwa 3,0 GB/s. Da für diesen Lesevorgang weder ausdrücklich direkte I/O verwendet noch der Seitencache geleert wurde, kann die Zwischenspeicherung den Wert beeinflusst haben.
Eine geringe Gesamtauslastung der CPU schließt einen Single-Thread-Flaschenhals nicht aus
Eine Kopierpipeline im Userspace kann einen Kern vollständig auslasten, während die gesamte CPU-Auslastung auf einem System mit vielen Kernen moderat bleibt. Überwache während des langsamen Files-Kopiervorgangs die CPU-Auslastung einzelner Threads und die Laufwerksauslastung.
Dieselbe große Datei über CLI und Files vergleichen
Verwende für Kopien mit Files und über die CLI dieselbe Quelle, dasselbe Ziel und dieselbe große Testdatei. Vergleiche die Ergebnisse anschließend mit einem direkt ausgeführten I/O-Benchmark, den du nach dem Test wieder löschen kannst. So lassen sich UI- und Backend-Overhead beim Kopieren von den Fähigkeiten des Rohgeräts trennen.
Dateianzahl und Btrfs-Metadaten können die tatsächliche Kopiergeschwindigkeit verändern
Tausende kleine Dateien erfordern wiederholte Metadatenoperationen, und das Copy-on-Write-Verhalten von Btrfs kann die Kosten eines internen Kopiervorgangs verändern.
Dies nicht als universelle aktuelle ZimaOS-Drosselung bezeichnen
Die Quelle liefert starke Belege für einen historischen Engpass beim Kopieren über Files beziehungsweise intern auf mehreren Systemen. Sie belegt jedoch nicht, dass ZimaOS 1.7.1 aktuell auf jeder Hardware- und Dateisystemkombination noch genau dieselbe Obergrenze hat.
Bei einem internen Kopiervorgang kann derselbe Speicher gleichzeitig lesen und schreiben
Liegen Quelle und Ziel auf derselben physischen NVMe oder im selben RAID-Pool, muss das Laufwerk Lese- und Schreibvorgänge gleichzeitig bedienen. Der sichtbare Kopierdurchsatz ist daher nicht mit einem sequenziellen Schreibbenchmark in nur eine Richtung vergleichbar.
Notiere vor dem Vergleich die physischen Quell- und Zielgeräte. „Interner Kopiervorgang“ beschreibt den Softwarepfad, nicht unbedingt zwei unabhängige SSDs.
Vor dem Vergleich mit Herstellerangaben PCIe-Linkbreite und -Generation prüfen
Eine leistungsstarke NVMe kann durch eine PCIe-x1- oder x2-Anbindung, eine ältere Generation, gemeinsam genutzte Chipsatz-Lanes oder eine Plattform eingeschränkt werden, deren Steckplatz anders angebunden ist, als es die physische Größe des Anschlusses vermuten lässt. Ein Rohbenchmark mit mehr als 2 GB/s schließt eine Obergrenze von 600 MB/s bereits aus, kann aber aus legitimen Gründen der Topologie weiterhin unter dem maximalen Desktop-Nennwert der SSD liegen.
Lange Kopiervorgänge können thermische oder SLC-Cache-Grenzen der SSD auslösen
Kurze Benchmarks und lange Dateikopiervorgänge belasten SSDs unterschiedlich. Ein Laufwerk kann zunächst sehr schnell sein und nach dem Füllen seines pseudo-SLC-Caches oder bei steigender Temperatur langsamer werden. Überwache die NVMe-Temperatur und den dauerhaften Durchsatz über einen ausreichend langen Zeitraum, bevor du jeden Rückgang Files zuschreibst.
Der Seitencache kann manche Tests schneller erscheinen lassen als das Gerät tatsächlich ist
Das direkte Schreibergebnis der Quelle ist aussagekräftig, weil dabei direkte I/O verwendet wurde. Lesetests, die unmittelbar nach dem Schreiben durchgeführt werden, können durch den Arbeitsspeicher-Cache beeinflusst werden, sofern der Benchmark diesen nicht ausdrücklich umgeht.
Für reproduzierbare Vergleiche solltest du eine Benchmark-Konfiguration verwenden, die angibt, ob direkte I/O aktiviert ist, und die Testdatei ausreichend groß wählen, um Verzerrungen durch den Cache zu verringern.
Den aktuellen Files-Kopierpfad erneut testen, bevor 600 MB/s als feste Produktgrenze betrachtet werden
Der Thread umfasst ZimaOS-Versionen vor der aktuellen Veröffentlichung. Wenn Files heute weiterhin begrenzt zu sein scheint, reproduziere den Effekt mit derselben großen Datei, derselben Quelle und demselben Ziel und vergleiche ihn mit einem aktuellen CLI-/Direkt-I/O-Test. So entstehen verwertbare Belege, anstatt eine alte numerische Obergrenze dauerhaft zu übernehmen.
FAQ zur NVMe-Geschwindigkeit
Hat die Quelle bewiesen, dass ZimaOS NVMe auf SATA-Geschwindigkeit begrenzt?
Nein. Direkte Schreibvorgänge mit dd und fio überschritten auf demselben System 2 GB/s.
Was wurde durch die Quelle am ehesten als Ursache nahegelegt?
Die interne Kopierpipeline der WebUI beziehungsweise des Dateimanagers oder der Overhead des Workloads – nicht das NVMe-Gerät selbst.
Sollte das Leseergebnis der gerade geschriebenen dd-Datei als reine Laufwerksgeschwindigkeit betrachtet werden?
Nicht unbedingt. Ohne direkte Lese-I/O und Kontrolle des Caches kann der Seitencache das Ergebnis beeinflussen.
