Att en Filer-kopiering i ZimaOS rapporterar ungefär 600–650 MB/s bevisar inte att själva NVMe-enheten är begränsad till SATA-hastighet. Källans community-guide skiljer korrekt mellan rå lagringsgenomströmning och genomströmning i filkopieringsarbetsflödet. En webbläsarbaserad filhanterare kan lägga till metadata, förloppsspårning, säkerhetslogik, kopiering i användarutrymmet, filsystemsoverhead och åtgärder per fil som inte mäts av ett direkt benchmark.
Det mest användbara tillvägagångssättet är jämförande: testa samma lagring med en stor sekventiell arbetsbelastning med direkt I/O och kopiera sedan samma stora fil via CLI och Filer. Om råa tester med direkt I/O ger flera GB/s medan GUI-kopieringen fortfarande ligger nära 600 MB/s, finns flaskhalsen sannolikt ovanför NVMe-enheten.
Ett enda filkopieringsresultat är inte ett NVMe-benchmark
Intern kopieringshastighet beror på:
- om källan och målet är samma eller olika enheter;
- filsystemtyp;
- copy-on-write-beteende;
- filstorlek och antal filer;
- CPU-belastning;
- sidcache;
- kopieringsimplementeringen.
Ett resultat på 600 MB/s kan vara utmärkt för ett arbetsflöde och dåligt för ett annat.
Börja med en stor sekventiell testfil
Stora filer minskar metadatabrus och gör det lättare att tolka varaktig genomströmning. Källan använde en fil på 10 GB så att arbetsbelastningen skulle pågå tillräckligt länge för att kunna observeras.
Innan du skapar en stor testfil bör du kontrollera att mållagringen har gott om ledigt utrymme. Ett benchmark som fyller system- eller datadisken kan orsaka ett annat fel.
Källan använde dd med direkta skrivningar
Community-guiden föreslog:
dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progressoflag=direct minskar effekterna av sidcachen vid skrivning. Detta är användbart för en grov kontroll av sekventiell skrivning.
Anta inte att varje bygge, enhet eller filsystem hanterar samma blockstorlek eller beteende för direkt I/O på identiskt sätt.
Var försiktigare när du tolkar källans dd-lästest
Källan läste sedan filen för att /dev/null. Utan ett alternativ för läsning med direkt I/O eller cachekontroll kan en nyligen skapad fil delvis läsas från sidcachen, vilket överdriver den upplevda läshastigheten.
För en tillförlitlig lagringsjämförelse bör du föredra ett verktyg eller en konfiguration som uttryckligen använder direkt I/O i båda riktningarna, eller se till att du förstår cacheeffekterna.
fio är ett bättre kontrollerat lagringsbenchmark
Källans exempel på varaktig skrivning använde:
fio --name=nvme --filename=/DATA/fio.test --size=10G --rw=write --bs=1M --iodepth=32 --numjobs=1 --direct=1 --runtime=30 --group_reportingDetta är fortfarande vägledning från communityn, men har en tydligare benchmarkstruktur: uttrycklig teststorlek, sekventiella skrivningar, ködjup, direkt I/O, körtid och grupperade resultat.
Rikta aldrig ett destruktivt fio-jobb mot en råenhet som innehåller verkliga data. Använd en tillfällig testfil på ett filsystem, såvida du inte fullt ut förstår konsekvenserna.
Jämför det grafiska gränssnittet och CLI med samma datamängd
Källans starkaste metodologiska råd är att använda samma stora fil för båda:
- en CLI-kopiering;
- en kopiering i ZimaOS Filer.
Om datamängden, källan, målet och filsystemet är identiska speglar skillnaden mer direkt kopieringsflödet.
Små filer kan vara dramatiskt långsammare
Tusentals foton, projektfiler, miniatyrbilder eller AppData-poster kräver upprepade öppnings-, skapande-, metadata- och kontrollsummeoperationer. Den sammanlagda överföringshastigheten kan sjunka långt under hastigheten för en enda stor film eller ISO, även på mycket snabba NVMe-enheter.
Btrfs copy-on-write och metadatahantering kan medföra ytterligare overhead beroende på den exakta åtgärden.
Övervaka CPU och I/O medan den långsamma kopieringen körs
Källan rekommenderar att diskbelastning och CPU övervakas samtidigt. Målet är att identifiera om:
- disken är mättad;
- en CPU-kärna är flaskhalsen;
- en annan process konkurrerar om I/O;
- kopieringsflödet väntar i stället för att belasta lagringen.
Detta är mer informativt än att bara ange siffran från förloppsindikatorn i Filer.
NVMe-hastighet beror också på PCIe-banor och enheten
Även en välfungerande NVMe-enhet kan köras under sitt marknadsförda värde om:
- kortplatsen använder PCIe x1/x2 i stället för x4;
- plattformen använder PCIe Gen 3 i stället för Gen 4;
- SSD-enheten stryps av värme;
- styrenheten delar banor;
- SLC-cachen tar slut under långvariga skrivningar.
Ett verkligt benchmark bör jämföras med hårdvarutopologin, inte med en generell förväntan om att ”NVMe = 7 GB/s”.
Aktuella överföringsguider från IceWhale skiljer också mellan gränssnittet och snabbare överföringsvägar
IceWhales Thunderbolt-guide för ZimaCube har historiskt visat att överföringsvägen i ZimaOS gränssnitt körs långsammare än en direkt Samba-/Thunderbolt-väg, vilket förstärker den allmänna poängen att filgränssnittet inte är identiskt med rå genomströmning för nätverk eller lagring.
Använd den aktuella felsökningschecklistan för ZimaOS-överföringar för kontroller på nätverkssidan som stöds.
Ta bort testfilerna när du är klar
Stor dd/fio Filer kan snabbt förbruka tiotals gigabyte. Ta bort de kända testfilerna efter att resultaten har registrerats och kontrollera det lediga utrymmet efteråt.
Vanliga frågor om NVMe-benchmarking
Bevisar 600 MB/s i ZimaOS Filer att NVMe-enheten är begränsad till SATA-hastighet?
Nej. Det mäter det kopieringsarbetsflödet, inte rå NVMe-kapacitet.
Varför kan en dd-läsning verka orealistiskt snabb?
En nyligen skriven fil kan delvis läsas från sidcachen, om lästestet inte uttryckligen kringgår cachelagring.
Vad är den bästa jämförelsen för kopieringsflödet i det grafiska gränssnittet?
Använd samma källa och mål samt samma stora datamängd i både CLI och Filer, och jämför sedan samtidigt som du övervakar CPU- och lagrings-I/O.
