poige está exatamente certo sobre o cache de gravação, mas aqui estão mais detalhes.
dd com zeros e usar cache de gravação não é o caminho certo para o benchmark (a menos que você queira testar o cache de gravação, claro, que é provavelmente útil apenas para um sistema de arquivos, para ver o quanto ele sincroniza metadados, cria novos arquivos , etc.) (e provavelmente dd é sempre o tipo errado de benchmark, mas funciona para um teste muito básico)
Sugiro que você use dd com pelo menos uma das seguintes opções:
conv=fdatasync -> this will make it flush to disk before finishing and calculating speed
oflag=direct -> this will make it skip the OS cache but not the disk cache
conv=sync -> more like skipping the disk cache too, but not really ... just flushing it every block or something like that.
E não use zero também. Alguns hardware / software / firmware inteligentes podem usar alguns atalhos se os dados forem tão previsíveis quanto zeros. Isto é especialmente verdadeiro se houver compressão que eu estou supondo que você não está usando. Em vez disso, use um arquivo aleatório na memória (como / dev / shm). O urandom é lento, então você precisa escrevê-lo em algum lugar temporariamente para lê-lo novamente. Crie um arquivo aleatório de 50 MB:
dd if=/dev/urandom of=/dev/shm/randfile bs=1M count=50
Leia o arquivo várias vezes para escrevê-lo (aqui eu uso cat para ler 6 vezes):
dd if=<(cat /dev/shm/randfile{,,,,,}) of= ... conv=fdatasync
rm /dev/shm/randfile
Lembre-se também de que as leituras de raid1 são mais rápidas com operações paralelas, portanto, os discos podem ser usados independentemente. Provavelmente não é inteligente o suficiente para coordenar os discos para ler partes diferentes da mesma operação com discos diferentes.