Se você quer precisão, você deve usar fio. Requer a leitura do manual ( man fio), mas fornecerá resultados precisos. Observe que, para qualquer precisão, você precisa especificar exatamente o que deseja medir. Alguns exemplos:
Velocidade de leitura sequencial com blocos grandes (isso deve ser próximo ao número que você vê nas especificações para sua unidade):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=read --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting
Velocidade de gravação seqüencial com blocos grandes (isso deve ser próximo ao número que você vê nas especificações para sua unidade):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=write --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting
QD1 de leitura aleatória em 4K (este é o número que realmente importa para o desempenho no mundo real, a menos que você saiba com certeza):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting
Leitura aleatória mista de 4K e gravação de QD1 com sincronização (este é o pior número esperado da sua unidade, geralmente menos de 1% dos números listados na folha de especificações):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting
Aumente o --sizeargumento para aumentar o tamanho do arquivo. O uso de arquivos maiores pode reduzir os números obtidos, dependendo da tecnologia e do firmware da unidade. Arquivos pequenos fornecerão resultados "muito bons" para mídia rotacional porque o cabeçote de leitura não precisa se mover muito. Se o seu dispositivo estiver quase vazio, usar um arquivo grande o suficiente para quase encher a unidade fornecerá o pior comportamento possível para cada teste. No caso de SSD, o tamanho do arquivo não importa muito.
No entanto, observe que, para algumas mídias de armazenamento, o tamanho do arquivo não é tão importante quanto o total de bytes gravados durante um curto período de tempo. Por exemplo, alguns SSDs podem ter um desempenho significativamente mais rápido com blocos pré-apagados ou podem ter uma pequena área de flash do SLC usada como cache de gravação e o desempenho muda quando o cache do SLC está cheio. Como outro exemplo, os HDDs da Seagate SMR têm cerca de 20 GB de área de cache PMR com desempenho bastante alto, mas, quando ficar cheio, gravar diretamente na área SMR pode reduzir o desempenho para 10% do original. E a única maneira de ver essa degradação do desempenho é primeiro escrever mais de 20 GB o mais rápido possível. Obviamente, tudo isso depende da sua carga de trabalho: se o acesso de gravação estiver cheio de atrasos prolongados que permitem que o dispositivo limpe o cache interno, sequências de teste mais curtas refletirão melhor seu desempenho no mundo real. Se você precisar fazer muito IO, precisará aumentar os dois--io_sizee --runtimeparâmetros. Observe que algumas mídias (por exemplo, a maioria dos dispositivos flash) terão desgaste extra com esses testes. Na minha opinião, se algum dispositivo é ruim o suficiente para não lidar com esse tipo de teste, ele não deve ser usado para armazenar dados valiosos em nenhum caso.
Além disso, alguns dispositivos SSD de alta qualidade podem ter algoritmos de nivelamento de desgaste ainda mais inteligentes, em que o cache SLC interno tem inteligência suficiente para substituir os dados que estão sendo reescritos durante o teste se atingir o mesmo espaço de endereço (ou seja, arquivo de teste é menor que o cache total do SLC). Para esses dispositivos, o tamanho do arquivo começa a importar novamente. Se você precisar da sua carga de trabalho real, é melhor testar com tamanhos de arquivo que você realmente verá na vida real. Caso contrário, seus números podem parecer bons demais.
Observe que fiocriará o arquivo temporário necessário na primeira execução. Ele será preenchido com dados aleatórios para evitar obter números muito bons de dispositivos que trapaceiam compactando os dados antes de gravá-los no armazenamento permanente. O arquivo temporário será chamado fio-tempfile.datnos exemplos acima e armazenado no diretório de trabalho atual. Portanto, você deve primeiro mudar para o diretório que está montado no dispositivo que deseja testar.
Se você tem um bom SSD e deseja ver números ainda mais altos, aumente --numjobsacima. Isso define a simultaneidade para as leituras e gravações. Todos os exemplos acima foram numjobsconfigurados para 1que o teste seja sobre leitura e gravação de processo único de encadeamento (possivelmente com uma fila configurada com iodepth). Os SSDs de ponta (por exemplo, Intel Optane) devem obter números altos mesmo sem aumentar numjobsmuito (por exemplo, 4devem ser suficientes para obter os números de especificação mais altos), mas alguns SSDs "corporativos" precisam de 32- 128para obter os números de especificação porque a latência interna desses dispositivos é maior, mas a taxa de transferência geral é insana.
