Het sterkste bewijs in deze brontekst is niet de Files-screenshot van 600 MB/s, maar de latere test met directe opslag-I/O. Een gebruiker bij wie het kopiëren via de ZimaOS-WebUI rond 600–650 MB/s bleef steken, mat met dd ongeveer 2,3 GB/s aan directe schrijfsnelheid en met fio ongeveer 2,2 GB/s. Dat sluit voor die machine een systeembrede verklaring uit waarbij “NVMe wordt begrensd tot SATA III”.
De meest verdedigbare conclusie is dat de lage snelheid bij de interne Files-kopieworkflow hoorde, of werd veroorzaakt door effecten van de kopieerbelasting, zoals metagegevens, Btrfs CoW, buffering of beperkingen door één thread — en niet door het fysieke NVMe-pad zelf.
De bron reproduceerde de beperking via meerdere kopieerpaden
Dave rapporteerde vergelijkbaar gedrag bij NVMe-naar-NVMe, NVMe-naar-RAID0, RAID0-naar-één NVMe en 10GbE-workflows. Een andere gebruiker meldde later dat SMB van Windows naar ZimaOS de volledige 10GbE-snelheid kon halen, terwijl een interne kopie via Files rond 650 MB/s bleef steken.
Directe schrijfbewerkingen met dd bereikten ongeveer 2,3 GB/s
In de bron werd dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progress gebruikt. Daarbij werd een resultaat van bijna 2,3 GB/s gemeld — ruim boven de praktische doorvoer van SATA III.
Ook fio bereikte ongeveer 2,2 GB/s
De fio-test uit de bron rapporteerde ongeveer 2163 MiB/s / 2268 MB/s aan schrijfsnelheid. Hoewel de gekozen synchrone engine de wachtrijd effectief beperkte tot één, bewees het resultaat nog steeds dat de opslagstack meerdere keren sneller kon zijn dan de kopieersnelheid in Files.
Interpreteer het dd-leesresultaat uit de bron zorgvuldig
In de bron werd ook ongeveer 3,0 GB/s gemeten bij het lezen van het zojuist geschreven testbestand naar /dev/null. Omdat bij die leesbewerking niet expliciet directe I/O of het leegmaken van de paginacache werd gebruikt, kan caching de meting hebben beïnvloed.
Een laag totaal CPU-gebruik sluit een bottleneck op één thread niet uit
Een kopieerpijplijn in de userspace kan één core volledig benutten, terwijl het totale CPU-gebruik op een systeem met veel cores bescheiden blijft. Controleer tijdens de trage kopie in Files het CPU-gebruik per thread en de schijfbelasting.
Vergelijk hetzelfde grote bestand via de CLI en Files
Gebruik voor kopieën via Files en de CLI dezelfde bron, bestemming en hetzelfde grote testbestand en vergelijk de resultaten vervolgens met een tijdelijke benchmark met directe I/O. Zo scheid je de overhead van de UI- en backend-kopieworkflow van de ruwe mogelijkheden van het opslagapparaat.
Het aantal bestanden en Btrfs-metagegevens kunnen de werkelijke kopieersnelheid veranderen
Bij duizenden kleine bestanden zijn herhaaldelijk metagegevensbewerkingen nodig, en het copy-on-write-gedrag van Btrfs kan de kosten van een interne kopie beïnvloeden.
Noem dit geen universele huidige ZimaOS-beperking
De bron levert sterk bewijs voor een historische bottleneck in Files of bij interne kopieën op meerdere systemen. De bron bewijst niet dat het huidige ZimaOS 1.7.1 op elke combinatie van hardware en bestandssysteem nog steeds exact hetzelfde plafond heeft.
Bij een interne kopie kan dezelfde opslag tegelijk lezen en schrijven
Als de bron en bestemming zich op dezelfde fysieke NVMe-schijf of in dezelfde RAID-pool bevinden, moet de schijf lees- en schrijfbewerkingen gelijktijdig verwerken. De zichtbare kopieersnelheid is daarom niet vergelijkbaar met een sequentiële schrijfb benchmark in één richting.
Noteer de fysieke bron- en bestemmingsapparaten voordat je resultaten vergelijkt. “Interne kopie” beschrijft het softwarepad en betekent niet noodzakelijk dat er twee onafhankelijke SSD's worden gebruikt.
Controleer de PCIe-linkbreedte en -generatie voordat je marketingcijfers vergelijkt
Een hoogwaardige NVMe-schijf kan worden beperkt door een PCIe x1- of x2-link, een oudere generatie, gedeeld gebruik van chipsetlanes of een platformslot dat anders is bedraad dan de fysieke connectorafmetingen doen vermoeden. Een ruwe benchmark van meer dan 2 GB/s sluit een plafond van 600 MB/s al uit, maar kan nog steeds lager liggen dan de maximale desktopspecificatie van de SSD vanwege legitieme topologieredenen.
Langdurige kopieën kunnen thermische of SLC-cachebeperkingen van SSD's activeren
Korte benchmarks en langdurige bestandskopieën belasten SSD's op verschillende manieren. Een schijf kan aanvankelijk zeer snel zijn en daarna vertragen zodra de pseudo-SLC-cache vol raakt of de temperatuur stijgt. Controleer de NVMe-temperatuur en de aanhoudende doorvoer gedurende een voldoende lange periode voordat je elke daling aan Files toeschrijft.
De paginacache kan sommige tests sneller laten lijken dan het apparaat werkelijk is
Het directe schrijfresultaat uit de bron is sterk bewijs, omdat daarbij directe I/O werd gebruikt. Leestests die onmiddellijk na het schrijven worden uitgevoerd, kunnen door de geheugencache worden beïnvloed tenzij de benchmark deze expliciet omzeilt.
Gebruik voor reproduceerbare vergelijkingen een benchmarkconfiguratie waarin staat of directe I/O is ingeschakeld en houd het testbestand groot genoeg om vertekening door caching te beperken.
Test de huidige Files-pijplijn opnieuw voordat je 600 MB/s als een vaste productlimiet beschouwt
De thread beslaat ZimaOS-versies van vóór de huidige release. Als Files vandaag nog steeds begrensd lijkt, reproduceer dit dan met hetzelfde grote bestand, dezelfde bron en bestemming en een actuele vergelijking met de CLI en directe I/O. Dat levert bruikbaar bewijs op in plaats van een oude numerieke grens voor onbepaalde tijd over te nemen.
Veelgestelde vragen over NVMe-snelheid
Heeft de bron bewezen dat ZimaOS NVMe beperkt tot SATA-snelheid?
Nee. Directe schrijfmetingen met dd en fio kwamen op hetzelfde systeem boven 2 GB/s uit.
Waar wees de bron het sterkst op?
Op de interne kopieerpijplijn van de WebUI/Bestandsbeheerder of op overhead door de werkbelasting, en niet op het NVMe-apparaat zelf.
Moet het leesresultaat van dd voor het zojuist geschreven bestand worden beschouwd als pure schijfsnelheid?
Niet noodzakelijk. Zonder directe lees-I/O of controle over de cache kan de paginacache het resultaat beïnvloeden.
