Com relação à diferença de 33x medida entre seus resultados, acompanhando nossa discussão nos comentários, descobriu-se que MegaCli64 -LDGetProp -DskCache -Lall -aAll mostrou que configuração B tinha o cache da unidade de disco habilitado por padrão, enquanto foi desativado na configuração A .
Usar MegaCli64 -LDSetProp -DisDskCache -Immediate -Lall -aAll resultou em ambos os sistemas mostrando um desempenho semelhante.
É seguro executar o RAID com o cache da unidade de disco ativado?
A execução de um RAID com cache de unidade de disco habilitado é, na verdade, semelhante à execução de um controlador RAID com cache volátil não suportado pela BBU com o cache de gravação ativado (modo de write-back forçado). Ele melhora o desempenho, mas ao mesmo tempo aumenta a possibilidade de perda de dados e inconsistência de dados no caso de falta de energia.
Se você quiser evitar essa chance, embora ainda tenha um desempenho de E / S decente, é aconselhável ter um controlador com cache suportado pela BBU e configurar seu volume para o modo write-back com o cache de disco desativado.
A diferença entre seus dois controladores RAID
Eu não sei se você já sabia, mas há mais entre software e hardware RAID ( este é um artigo interessante sobre isso ).
No final, o MegaRAID SAS 2008 é mais ou menos um HBA ou IO-Controller com capacidade RAID adicionada, enquanto o MegaRAID SAS 3108 é um controlador RAID real (também chamado de ROC ou RAID-on-Chip), que possui um processador dedicado para manipular os cálculos RAID.
O SAS 2008 é especialmente conhecido pelo desempenho horrível de gravação com alguns firmwares OEM (como o da DELL no PERC H310 que mencionei no comentário).
Especialmente o modo síncrono em combinação com o comprimento de registro e o tamanho de arquivo escolhidos parece resultar em resultados realmente ruins com software / falso RAID.
Para referência, é isso que recebo em minha estação de trabalho usando o WD Velocity Raptors de 10k no software RAID1:
random random bkwd record stride
KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
10240 4 182 181 1804774 2127084 2110984 167 1673159 153 1760968 954589 1203989 2022512 2062824
Se você estiver executando em modo síncrono (O_SYNC), seu Resultado A parece ser razoável em termos do que pode ser fornecido via soft / fake-RAID.
O modo de cache write-through causa uma degradação do desempenho do array ao longo do tempo?
Eu não penso assim. Com um cache de gravação ativado, o controlador é capaz de realizar certas operações para otimizar as operações de gravação pendentes.
Por exemplo, esta descrição da operação de cache é retirada do whitepaper para controladores HP Smart Array:
The write cache will typically fill up and remain full most of the time in high-workload environments. The controller uses this opportunity to analyze the pending write commands to improve their efficiency. The controller can use write coalescing that combines small writes to adjacent logical blocks into a single larger write for quicker execution. The controller can also perform command reordering, rearranging the execution order of the writes in the cache to reduce the overall disk latency.
Como você pode ler, o cache é usado para melhorar ainda mais o desempenho de gravação da matriz, mas isso não parece ter qualquer impacto sobre o desempenho de qualquer operação de gravação ou leitura subsequente.
Em relação à fragmentação de disco, esse é um problema no sistema de arquivos / sistema operacional. O controlador RAID - operando no nível de bloco - não é capaz de otimizar a fragmentação do sistema de arquivos, portanto, não há diferença se ele opera no modo write-trough ou write-back .