Por que o diskspd e o fio geram números ímpares no Linux versus Windows?

Question

UPDATE

Graças à resposta de Anon, descobri que o sistema de arquivos estava em falta - usei o NTFS. A seguir estão os resultados usando o FAT32.

Windows:

diskspd64 -b128K -d5 -o32 -t1 -W0 -Sh -w0 cdm
508, 518, 520, 513, 513

fio --name=dontknow --ioengine=windowsaio --thread --size=1024m --bs=128k --time_based=1 --runtime=5s --iodepth=32 --numjobs=1 --rw=read --direct=1 --buffered=0 --startdelay=0s --filename=cdm
557, 557, 557, 558, 556

Linux:

diskspd -b128K -d5 -o32 -t1 -W0 -Sh -w0 cdm
529, 528, 529, 529, 529

fio --name=dontknow --ioengine=libaio --thread --size=1024m --bs=128k --time_based=1 --runtime=5s --iodepth=32 --numjobs=1 --rw=read --direct=1 --buffered=0 --startdelay=0s --filename=cdm
560, 560, 560, 560, 559

PERGUNTA ORIGINAL

Com base no mesmo arquivo de entrada na mesma unidade, esses são os números resultantes da velocidade de leitura (MB / s - eu corri cada 5 vezes) para determinados comandos no Windows:

diskspd64 -b128k -d5 -o32 -t1 -W0 -S -w0 cdm
555, 555, 556, 556, 555

fio --name=doesntmatter --ioengine=windowsaio --thread=1 --size=1024m --bs=128k --time_based=1 --runtime=5s --iodepth=32 --numjobs=1 --rw=read --direct=1 --startdelay=0s --filename=cdm
561, 553, 562, 561, 558

E Linux (para ser mais preciso - KDE neon useredition-20180802):

diskspd -b128K -d5 -o32 -t1 -W0 -Sh -w0 cdm
1800, 2000, 1925, 1891, 1973

fio --name=doesntmatter --ioengine=libaio --thread=1 --size=1024m --bs=128k --time_based=1 --runtime=5s --iodepth=32 --numjobs=1 --rw=read --direct=1 --startdelay=0s --filename=cdm
2637, 2826, 2593, 2770

Gostaria também de mencionar que esta é uma unidade SSD SATA com uma velocidade máxima oficial de leitura de 555 MB/s . Então os números do Windows parecem ser precisos.

    

Answer 1

Infelizmente não há informações suficientes para responder à sua pergunta - muitas vezes é necessário ver a saída completa da sua corrida e saber qual versão do fio está sendo executada, pois isso pode dizer coisas como quais profundidades são alcançadas e como o Linux está ocupado Pensei que o disco estava durante a execução (por exemplo, quando as latências estão próximas de 0, o que é quase sempre um sinal de armazenamento em cache).

Pode ser que o sistema de arquivos no qual o arquivo está não suporte direct=1 com as opções que está usando . Pode ser que seu arquivo tenha sido totalmente armazenado em cache por algum motivo e você esteja apenas lendo de volta a partir do cache (atente para isso quando os tamanhos dos arquivos são muito menores do que o total de RAM). Pode ser que você não tenha escrito no seu arquivo, ele é escasso / vazio e não está realmente "lá" (tente fazer um conjunto completo de gravações antes de lê-lo de volta) ...

PS: thread não precisa ter um valor (consulte link ).