Een ZimaOS Files-kopieeractie die ongeveer 600–650 MB/s rapporteert, bewijst niet dat het NVMe-apparaat zelf beperkt is tot SATA-snelheid. De communitygids uit de bron maakt terecht onderscheid tussen raw opslagdoorvoer en doorvoer van de workflow voor het kopiëren van bestanden. Een bestandsbeheerder in de browser kan metadata, voortgangsregistratie, veiligheidslogica, kopieën in de gebruikersruimte, overhead van het bestandssysteem en bewerkingen per bestand toevoegen die een directe benchmark niet meet.
De nuttigste aanpak is vergelijkend: test dezelfde opslag met een grote sequentiële workload met directe I/O en kopieer vervolgens hetzelfde grote bestand via de CLI en Files. Als raw/direct tests meerdere GB/s opleveren terwijl de GUI-kopieeractie rond 600 MB/s blijft, bevindt de bottleneck zich waarschijnlijk boven het NVMe-apparaat.
Eén getal voor bestandsoverdracht is geen NVMe-benchmark
De interne kopieersnelheid hangt af van:
- bron en doel op hetzelfde of op verschillende apparaten;
- bestandssysteemtype;
- copy-on-write-gedrag;
- bestandsgrootte en het aantal bestanden;
- CPU-overhead;
- paginacache;
- de kopieerimplementatie.
Een resultaat van 600 MB/s kan voor de ene workflow uitstekend zijn en voor een andere slecht.
Begin met een groot sequentieel testbestand
Grote bestanden verminderen metadata-overhead en maken het gemakkelijker om aanhoudende doorvoer te interpreteren. De bron gebruikte een bestand van 10 GB, zodat de workload lang genoeg zou duren om deze te kunnen observeren.
Controleer voordat je een groot testbestand maakt of de doelopslag voldoende vrije ruimte heeft. Een benchmark die de systeem- of gegevensschijf vult, kan een ander probleem veroorzaken.
De bron gebruikte dd met directe schrijfbewerkingen
De communitygids stelde het volgende voor:
dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progressoflag=direct vermindert de effecten van de paginacache tijdens het schrijven. Dit is nuttig voor een ruwe controle van sequentiële schrijfsnelheid.
Ga er niet van uit dat elke build, elk apparaat en elk bestandssysteem dezelfde blokgrootte of hetzelfde gedrag voor directe I/O identiek accepteert.
Wees voorzichtiger bij het interpreteren van de dd-leestest uit de bron
De bron las het bestand vervolgens om /dev/nullZonder een optie voor lezen met directe I/O of cachebeheer kan een recent bestand gedeeltelijk vanuit de paginacache worden geleverd, waardoor de schijnbare leessnelheid overdreven hoog uitvalt.
Gebruik voor een betrouwbare opslagvergelijking bij voorkeur een tool/configuratie die expliciet directe I/O in beide richtingen gebruikt, of zorg dat je de effecten van caching begrijpt.
fio is de beter gecontroleerde opslagbenchmark
In het voorbeeld van de bron voor aanhoudend schrijven werd het volgende gebruikt:
fio --name=nvme --filename=/DATA/fio.test --size=10G --rw=write --bs=1M --iodepth=32 --numjobs=1 --direct=1 --runtime=30 --group_reportingDit is nog steeds communityadvies, maar het heeft een duidelijkere benchmarkopzet: expliciete testgrootte, sequentiële schrijfbewerkingen, wachtrijdiepte, directe I/O, looptijd en gegroepeerde resultaten.
Wijs nooit een destructieve fio-taak naar een raw device dat echte gegevens bevat. Gebruik een wegwerpbaar testbestand op een bestandssysteem, tenzij je de gevolgen volledig begrijpt.
Vergelijk GUI en CLI met dezelfde dataset
Het belangrijkste methodologische advies van de bron is om voor beide dezelfde grote bestanden te gebruiken:
- een kopie via de CLI;
- een kopie in ZimaOS Bestanden.
Als de dataset, bron, bestemming en het bestandssysteem identiek zijn, weerspiegelt het verschil de kopieerpijplijn directer.
Kleine bestanden kunnen dramatisch trager zijn
Duizenden foto's, projectbestanden, miniaturen of AppData-vermeldingen vereisen herhaaldelijk openen, aanmaken en uitvoeren van metadata- en checksum-bewerkingen. De totale overdrachtssnelheid kan daardoor ver onder die van één grote film of ISO uitkomen, zelfs op zeer snelle NVMe.
Copy-on-write- en metadatagedrag van Btrfs kunnen afhankelijk van de exacte bewerking extra overhead veroorzaken.
Houd CPU en I/O in de gaten terwijl de trage kopie wordt uitgevoerd
De bron raadt aan om het schijfgebruik en de CPU tegelijkertijd te observeren. Het doel is vast te stellen of:
- de schijf verzadigd is;
- één CPU-core de bottleneck is;
- een ander proces om I/O concurreert;
- de kopieerpijplijn wacht in plaats van de opslag aan te sturen.
Dit is informatiever dan alleen het getal uit de voortgangsbalk van Bestanden te citeren.
NVMe-snelheid hangt ook af van PCIe-lanes en het apparaat
Zelfs een gezonde NVMe kan onder het marketingcijfer blijven als:
- de sleuf PCIe x1/x2 in plaats van x4 is;
- het platform PCIe Gen 3 in plaats van Gen 4 gebruikt;
- de SSD thermisch wordt begrensd;
- de controller lanes deelt;
- De SLC-cache is uitgeput tijdens aanhoudende schrijfbewerkingen.
Een echte benchmark moet worden vergeleken met de hardwaretopologie, niet met een algemene verwachting als ‘NVMe = 7 GB/s’.
Huidige overdrachtsgidsen van IceWhale scheiden de UI- en snellere overdrachtspaden ook
De Thunderbolt-gids van IceWhale voor ZimaCube liet historisch gezien zien dat het overdrachtspad via de ZimaOS-gebruikersinterface trager werkt dan een rechtstreeks Samba-/Thunderbolt-pad, wat het algemene punt versterkt dat de bestandsinterface niet identiek is aan de onbewerkte netwerk- of opslagdoorvoer.
Gebruik de huidige checklist voor het oplossen van problemen met ZimaOS-overdrachten voor ondersteunde controles aan de netwerkkant.
Testbestanden verwijderen wanneer je klaar bent
Groot dd/fio Bestanden kunnen snel tientallen gigabytes in beslag nemen. Verwijder de bekende testbestanden nadat je de resultaten hebt vastgelegd en controleer daarna of er voldoende vrije ruimte is.
Veelgestelde vragen over NVMe-benchmarks
Bewijst 600 MB/s in ZimaOS Bestanden dat de NVMe beperkt is tot SATA-snelheid?
Nee. Dit meet die kopieerworkflow, niet de onbewerkte NVMe-capaciteit.
Waarom kan een dd-leesbewerking onrealistisch snel lijken?
Een recent geschreven bestand kan gedeeltelijk vanuit de paginacache worden aangeboden, tenzij de leestest caching expliciet vermijdt.
Wat is de beste vergelijking voor de kopieerpijplijn van de GUI?
Gebruik dezelfde bron/bestemming en dezelfde grote dataset in zowel de CLI als Bestanden, en vergelijk ze terwijl je het CPU- en opslag-I/O-gebruik monitort.
