Una copia in ZimaOS Files che riporta circa 600–650 MB/s non dimostra che il dispositivo NVMe sia limitato alla velocità SATA. La guida della community della fonte distingue correttamente il throughput dello storage raw dal throughput del flusso di lavoro di copia dei file. Un file manager basato su browser può aggiungere metadati, monitoraggio dell'avanzamento, logica di sicurezza, copie in userspace, overhead del filesystem e operazioni per singolo file che un benchmark diretto non misura.
L'approccio più utile è comparativo: testa lo stesso storage con un carico di lavoro sequenziale di grandi dimensioni con I/O diretto, quindi copia lo stesso file di grandi dimensioni tramite CLI e Files. Se i test raw/diretti raggiungono diversi GB/s mentre la copia tramite GUI rimane intorno ai 600 MB/s, il collo di bottiglia è probabilmente al di sopra del dispositivo NVMe.
Un solo valore di copia dei file non è un benchmark NVMe
La velocità della copia interna dipende da:
- stessa o diversa unità per origine e destinazione;
- tipo di filesystem;
- comportamento copy-on-write;
- dimensione e numero dei file;
- carico della CPU;
- page cache;
- l'implementazione della copia.
Un risultato di 600 MB/s può essere eccellente per un flusso di lavoro e scarso per un altro.
Inizia con un file di test sequenziale di grandi dimensioni
I file di grandi dimensioni riducono il rumore dei metadati e rendono più facile interpretare il throughput sostenuto. La fonte utilizzava un file da 10 GB affinché il carico di lavoro durasse abbastanza a lungo da poterlo osservare.
Prima di creare un file di test di grandi dimensioni, verifica che lo storage di destinazione disponga di molto spazio libero. Un benchmark che riempie il disco di sistema o dei dati può causare un problema diverso.
La fonte utilizzava dd con scritture dirette
La guida della community proponeva:
dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progressoflag=direct riduce gli effetti della page cache sul percorso di scrittura. È utile per un controllo approssimativo della scrittura sequenziale.
Non presumere che ogni build, dispositivo o filesystem accetti allo stesso modo la dimensione dei blocchi o il comportamento dell'I/O diretto.
Interpreta con maggiore cautela il test di lettura dd della fonte
La fonte ha quindi letto il file per /dev/null. Senza un'opzione di lettura con I/O diretto o un controllo della cache, un file recente può essere servito parzialmente dalla page cache, esagerando la velocità di lettura apparente.
Per un confronto affidabile dello storage, preferisci uno strumento o una configurazione che utilizzi esplicitamente l'I/O diretto in entrambe le direzioni, oppure assicurati di comprendere gli effetti della cache.
fio è il benchmark dello storage più controllato
L'esempio di scrittura sostenuta della fonte utilizzava:
fio --name=nvme --filename=/DATA/fio.test --size=10G --rw=write --bs=1M --iodepth=32 --numjobs=1 --direct=1 --runtime=30 --group_reportingQuesta è ancora una guida della community, ma ha una struttura di benchmark più chiara: dimensione del test esplicita, scritture sequenziali, profondità della coda, I/O diretto, durata e risultati raggruppati.
Non indirizzare mai un processo fio distruttivo verso un dispositivo raw contenente dati reali. Usa un file di test usa e getta su un filesystem, a meno che tu non comprenda pienamente le conseguenze.
Confronta la GUI e la CLI con lo stesso dataset
Il consiglio metodologico più importante della fonte è usare lo stesso file di grandi dimensioni per entrambi:
- una copia tramite CLI;
- una copia tramite File di ZimaOS.
Se il dataset, l'origine, la destinazione e il filesystem sono identici, la differenza riflette più direttamente la pipeline di copia.
I file di piccole dimensioni possono essere molto più lenti
Migliaia di foto, file di progetto, miniature o voci AppData richiedono ripetute operazioni di apertura, creazione, gestione dei metadati e checksum. La velocità di trasferimento complessiva può scendere molto al di sotto di quella di un singolo filmato o ISO di grandi dimensioni, anche su un NVMe molto veloce.
Il copy-on-write di Btrfs e la gestione dei metadati possono aggiungere ulteriore overhead, a seconda dell'operazione esatta.
Monitora CPU e I/O durante l'esecuzione della copia lenta
La fonte consiglia di osservare contemporaneamente l'utilizzo del disco e della CPU. L'obiettivo è determinare se:
- il disco è saturo;
- un singolo core della CPU è il collo di bottiglia;
- un altro processo sta competendo per l'I/O;
- la pipeline di copia è in attesa invece di sfruttare lo storage;
Questo è più informativo che citare soltanto il valore della barra di avanzamento di File.
La velocità NVMe dipende anche dalle linee PCIe e dal dispositivo
Anche un NVMe perfettamente funzionante può operare al di sotto del valore dichiarato dal produttore se:
- lo slot è PCIe x1/x2 anziché x4;
- la piattaforma è PCIe Gen 3 anziché Gen 4;
- l'SSD sta riducendo le prestazioni a causa della temperatura;
- il controller condivide le linee;
- La cache SLC si esaurisce durante le scritture prolungate.
Un benchmark reale dovrebbe essere confrontato con la topologia hardware, non con l'aspettativa generica «NVMe = 7 GB/s».
Anche le guide attuali di IceWhale sui trasferimenti separano i percorsi dell'interfaccia da quelli più veloci
La guida Thunderbolt di ZimaCube di IceWhale ha storicamente mostrato che il percorso di trasferimento nell'interfaccia di ZimaOS è più lento rispetto a un percorso diretto Samba/Thunderbolt, rafforzando il concetto generale che l'interfaccia per i file non è identica al throughput grezzo della rete o dello storage.
Usa l'elenco aggiornato per la risoluzione dei problemi di trasferimento di ZimaOS per i controlli supportati sul lato rete.
Elimina i file di test al termine
Grande dd/fio i file possono consumare rapidamente decine di gigabyte. Elimina i file di test noti dopo aver registrato i risultati e verifica lo spazio libero in seguito.
Domande frequenti sui benchmark NVMe
600 MB/s in File di ZimaOS dimostrano che l'NVMe è limitato alla velocità SATA?
No. Misura quel flusso di lavoro di copia, non le capacità grezze dell'NVMe.
Perché una lettura con dd può sembrare irrealisticamente veloce?
Un file scritto di recente può essere servito in parte dalla cache delle pagine, a meno che il test di lettura non eviti esplicitamente la memorizzazione nella cache.
Qual è il confronto migliore per la pipeline di copia della GUI?
Usa la stessa origine, la stessa destinazione e lo stesso dataset di grandi dimensioni sia nella CLI sia in File, quindi confronta i risultati monitorando CPU e I/O dello storage.
