Det starkaste beviset i den här källtråden är inte skärmbilden med 600 MB/s i Files – det är det senare direktlagringstestet. En användare vars kopiering i ZimaOS WebUI låg kvar runt 600–650 MB/s uppmätte ungefär 2,3 GB/s vid direkta skrivningar med dd och cirka 2,2 GB/s vid skrivningar med fio. Det utesluter en övergripande förklaring om att ”NVMe är begränsat till SATA III” på den maskinen.
Den mer hållbara slutsatsen är att den långsamma hastigheten berodde på den interna kopieringsprocessen i Files eller på effekter kopplade till kopieringsbelastningen, såsom metadata, Btrfs CoW, buffring eller begränsningar med en enda tråd – inte på själva den fysiska NVMe-sökvägen.
Källan återskapade begränsningen via flera kopieringsvägar
Dave rapporterade liknande beteende vid arbetsflöden från en NVMe-enhet till en annan, från NVMe till RAID0, från RAID0 till en enskild NVMe-enhet samt via 10GbE. En annan användare uppgav senare att SMB-kopiering från Windows till ZimaOS kunde nå full 10GbE-hastighet, medan intern Files-kopiering fortfarande låg kvar runt 650 MB/s.
Direkta skrivningar med dd nådde cirka 2,3 GB/s
Källan använde dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progress och publicerade ett resultat nära 2,3 GB/s – långt över den praktiska genomströmningen för SATA III.
fio nådde också cirka 2,2 GB/s
Källans fio-körning rapporterade ungefär 2163 MiB/s / 2268 MB/s vid skrivning. Även om den valda synkrona motorn i praktiken begränsade ködjupet till ett, visade resultatet ändå att lagringsstacken kunde överstiga Files-kopieringens hastighet flera gånger om.
Tolka källans läshastighet med dd försiktigt
Källan uppmätte också omkring 3,0 GB/s vid läsning av den nyligen skrivna testfilen till /dev/null. Eftersom läsningen inte uttryckligen använde direkt I/O eller tömde sidcachen kan cachelagring ha påverkat resultatet.
Låg total CPU-användning utesluter inte en flaskhals med en enda tråd
En kopieringspipeline i användarutrymmet kan belasta en kärna maximalt samtidigt som den totala CPU-användningen förblir måttlig på ett system med många kärnor. Övervaka CPU-användningen per tråd och diskanvändningen under den långsamma Files-kopieringen.
Jämför samma stora fil via CLI och Files
Använd samma källa, destination och stora testfil för kopiering via Files och CLI, och jämför sedan med ett direkt I/O-prestandatest som kan köras utan följder. På så sätt skiljer du omkostnader i gränssnittet eller backend-kopieringen från enhetens råa kapacitet.
Antalet filer och Btrfs-metadata kan påverka den verkliga kopieringshastigheten
Tusentals små filer kräver upprepade metadataoperationer, och Btrfs copy-on-write-beteende kan förändra kostnaden för en intern kopiering.
Kalla inte detta en universell aktuell begränsning i ZimaOS
Källan ger starka belägg för en historisk flaskhals i Files eller intern kopiering på flera system. Den visar däremot inte att nuvarande ZimaOS 1.7.1 fortfarande har exakt samma tak på alla kombinationer av hårdvara och filsystem.
En intern kopiering kan läsa från och skriva till samma lagring samtidigt
Om källan och destinationen finns på samma fysiska NVMe-enhet eller i samma RAID-pool måste enheten hantera läsningar och skrivningar samtidigt. Den synliga kopieringshastigheten är därför inte jämförbar med ett sekventiellt skrivtest i en enda riktning.
Notera de fysiska käll- och destinationsenheterna innan du jämför resultat. ”Intern kopiering” beskriver programvaruvägen, inte nödvändigtvis två separata SSD-enheter.
Kontrollera PCIe-länkens bredd och generation innan du jämför marknadsförda siffror
En avancerad NVMe-enhet kan begränsas av en PCIe x1-/x2-länk, en äldre generation, delade chipsetbanor eller en plattformsplats som är ansluten på ett annat sätt än vad den fysiska kontakten antyder. Ett råprestandatest som når över 2 GB/s utesluter redan ett tak på 600 MB/s, men hastigheten kan fortfarande ligga under SSD-enhetens maximala skrivbordsspecifikation av legitima topologiska skäl.
Långa kopieringar kan utlösa SSD-begränsningar på grund av temperatur eller SLC-cache
Korta prestandatester och långa filkopieringar belastar SSD-enheter på olika sätt. En enhet kan börja mycket snabbt och sedan sjunka när dess pseudo-SLC-cache fylls eller temperaturen stiger. Övervaka NVMe-temperaturen och den långvariga genomströmningen under ett tillräckligt långt tidsintervall innan du tillskriver varje hastighetsminskning Files.
Sidcache kan få vissa tester att se snabbare ut än enheten faktiskt är
Källans direkta skrivresultat är starka belägg eftersom direkt I/O användes. Läsningar som utförs omedelbart efter skrivning kan påverkas av minnescache, om inte prestandatestet uttryckligen kringgår den.
Använd en testkonfiguration som anger om direkt I/O är aktiverat för jämförbara resultat, och se till att testfilen är tillräckligt stor för att minska cachepåverkan.
Testa den aktuella Files-pipelinen igen innan du betraktar 600 MB/s som en fast produktbegränsning
Tråden sträcker sig över ZimaOS-versioner från tiden före den aktuella utgåvan. Om Files fortfarande verkar vara begränsat i dag bör du återskapa testet med samma stora fil, samma källa och destination samt en aktuell jämförelse via CLI och direkt I/O. Det ger användbara belägg i stället för att ett gammalt hastighetstak förs vidare på obestämd tid.
Vanliga frågor om NVMe-hastighet
Visade källan att ZimaOS begränsar NVMe till SATA-hastighet?
Nej. Direkta skrivningar med dd och fio översteg 2 GB/s på samma system.
Vad pekade källan främst ut?
Den interna kopieringspipelinen i WebUI eller filhanteraren, eller omkostnader kopplade till arbetsbelastningen, snarare än själva NVMe-enheten.
Ska läsresultatet med dd efter den nyliga skrivningen betraktas som en ren diskhastighet?
Inte nödvändigtvis. Utan direkt läs-I/O eller kontroll av cache kan sidcachen påverka resultatet.
