La prova più solida in questo thread di discussione non è lo screenshot dei File da 600 MB/s, bensì il successivo test di archiviazione diretta. Un utente, la cui copia tramite WebUI di ZimaOS rimaneva intorno ai 600–650 MB/s, ha misurato circa 2,3 GB/s nelle scritture dirette con dd e circa 2,2 GB/s nelle scritture con fio. Questo esclude, per quella macchina, l’ipotesi che a livello di sistema operativo “l’NVMe sia limitato a SATA III”.
La conclusione più sostenibile è che il valore ridotto riguardasse il flusso di lavoro della copia interna di Files oppure gli effetti del carico di copia, come metadati, CoW di Btrfs, buffering o limiti single-thread, e non il percorso fisico NVMe in sé.
La fonte ha riprodotto il limite attraverso diversi percorsi di copia
Dave ha segnalato un comportamento simile con NVMe singolo-NVMe singolo, NVMe-RAID0, RAID0-NVMe singolo e flussi di lavoro 10GbE. In seguito, un altro utente ha riferito che la copia da Windows a ZimaOS tramite SMB poteva raggiungere la piena velocità 10GbE, mentre la copia interna di Files rimaneva intorno ai 650 MB/s.
Le scritture dirette con dd hanno raggiunto circa 2,3 GB/s
La fonte ha usato dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progress e ha pubblicato un risultato vicino ai 2,3 GB/s, ben al di sopra della velocità pratica di SATA III.
Anche fio ha raggiunto circa 2,2 GB/s
L’esecuzione di fio della fonte ha riportato scritture di circa 2163 MiB/s / 2268 MB/s. Sebbene il motore sincrono selezionato limitasse di fatto la profondità della coda a uno, il risultato ha comunque dimostrato che lo stack di archiviazione poteva superare di diverse volte il valore della copia di Files.
Interpretate con cautela il valore di lettura con dd della fonte
La fonte ha misurato anche circa 3,0 GB/s leggendo il file di test appena scritto verso /dev/null. Poiché la lettura non utilizzava esplicitamente l’I/O diretto né svuotava la cache delle pagine, il caching potrebbe aver influito sul valore.
Un utilizzo complessivo ridotto della CPU non esclude un collo di bottiglia single-thread
Una pipeline di copia in user space può saturare un singolo core mentre l’utilizzo complessivo della CPU rimane moderato su un sistema con molti core. Durante la copia lenta di Files, monitorate l’utilizzo della CPU per thread e quello del disco.
Confrontate lo stesso file di grandi dimensioni tra CLI e Files
Usate la stessa origine, la stessa destinazione e lo stesso file di test di grandi dimensioni per le copie con Files e CLI, quindi confrontate i risultati con un benchmark di I/O diretto temporaneo. In questo modo è possibile distinguere il sovraccarico della copia dell’interfaccia/backend dalle capacità effettive del dispositivo.
Il numero di file e i metadati Btrfs possono modificare la velocità reale di copia
Migliaia di file piccoli richiedono operazioni ripetute sui metadati, mentre il comportamento copy-on-write di Btrfs può modificare il costo di una copia interna.
Non definite questo valore come un limite universale attuale di ZimaOS
La fonte fornisce prove solide di un collo di bottiglia storico di Files/copia interna su più sistemi. Non dimostra però che ZimaOS 1.7.1 abbia ancora oggi esattamente lo stesso limite su ogni combinazione di hardware e filesystem.
Una copia interna può leggere e scrivere contemporaneamente sullo stesso dispositivo di archiviazione
Se origine e destinazione si trovano sullo stesso NVMe fisico o nello stesso pool RAID, l’unità deve gestire simultaneamente letture e scritture. Il throughput di copia visibile non è quindi confrontabile con un benchmark di scrittura sequenziale unidirezionale.
Annotate i dispositivi fisici di origine e destinazione prima di confrontare i risultati. “Copia interna” descrive il percorso software, non necessariamente due SSD indipendenti.
Controllate larghezza e generazione del collegamento PCIe prima di confrontare i valori dichiarati
Un NVMe di fascia alta può essere limitato da un collegamento PCIe x1/x2, da una generazione precedente, dalla condivisione delle linee del chipset o da uno slot della piattaforma cablato diversamente rispetto alle sue dimensioni fisiche. Un benchmark diretto che raggiunge oltre 2 GB/s esclude già un limite a 600 MB/s, ma potrebbe comunque essere inferiore al massimo dichiarato per l’SSD in ambito desktop per legittimi motivi legati alla topologia.
Le copie prolungate possono attivare i limiti termici o della cache SLC dell’SSD
I benchmark brevi e le copie di file prolungate sottopongono gli SSD a carichi diversi. Un’unità può iniziare a velocità molto elevata e poi rallentare quando la cache pseudo-SLC si esaurisce o la temperatura aumenta. Monitorate la temperatura dell’NVMe e il throughput sostenuto per un intervallo sufficientemente lungo prima di attribuire ogni calo a Files.
La cache delle pagine può far apparire alcuni test più veloci del dispositivo
Il risultato della scrittura diretta della fonte è una prova solida perché utilizzava l’I/O diretto. I test di lettura eseguiti subito dopo una scrittura possono essere influenzati dalla cache della memoria, a meno che il benchmark non la bypassi esplicitamente.
Per confronti ripetibili, usate una configurazione di benchmark che indichi se l’I/O diretto è abilitato e mantenete le dimensioni del file di test abbastanza grandi da ridurre le distorsioni dovute alla cache.
Ripetete il test dell’attuale pipeline di Files prima di considerare 600 MB/s un limite fisso del prodotto
Il thread riguarda versioni di ZimaOS precedenti alla release attuale. Se Files sembra ancora limitato oggi, riproducete il test con lo stesso file di grandi dimensioni, la stessa origine e destinazione e un confronto attuale tra CLI e I/O diretto. In questo modo otterrete prove utili invece di perpetuare indefinitamente un vecchio limite numerico.
Domande frequenti sulla velocità degli NVMe
La fonte ha dimostrato che ZimaOS limita gli NVMe alla velocità di SATA?
No. Le scritture dirette con dd e fio hanno superato i 2 GB/s sullo stesso sistema.
Che cosa ha indicato più chiaramente la fonte?
La pipeline di copia interna della WebUI/Gestione file o il sovraccarico del carico di lavoro, piuttosto che il dispositivo NVMe in sé.
Il risultato della lettura con dd del file appena scritto deve essere considerato la velocità pura del disco?
Non necessariamente. Senza I/O diretto in lettura o controllo della cache, la cache delle pagine può influire sul risultato.
