Francamente, acho surpreendente que você rejeitaria o RAIDZ2 ZFS. Parece se adequar às suas necessidades quase perfeitamente, exceto pelo fato de não ser o Linux MD. Eu não estou em uma cruzada para trazer o ZFS para as massas, mas o simples fato é que o seu é um dos tipos de problemas que o ZFS foi projetado do zero para resolver. Confiar no RAID (qualquer RAID "regular") para fornecer detecção e correção de erros, possivelmente em uma situação reduzida ou sem redundância, parece arriscado. Mesmo em situações em que o ZFS não consegue corrigir corretamente um erro de dados, ele pode, pelo menos, detectar o erro e informar que há um problema, permitindo que você tome uma ação corretiva.
Você não tem para executar scrubs completos regulares com o ZFS, embora seja uma prática recomendada. O ZFS verificará se os dados lidos do disco correspondem ao que foi gravado conforme os dados estão sendo lidos e, no caso de incompatibilidade, (a) usará redundância para reconstruir os dados originais ou (b) reportará um erro de E / S para a aplicação. Além disso, o scrubbing é uma operação on-line de baixa prioridade, bem diferente de uma verificação do sistema de arquivos na maioria dos sistemas de arquivos, que podem ser de alta prioridade e off-line. Se você estiver executando um scrub e algo diferente do scrub quer fazer I / O, o scrub ficará no banco de trás enquanto durar. Um scrub do ZFS toma o lugar de um scrid RAID e uma verificação de integridade dos metadados do sistema de arquivos e dados , portanto é muito mais completo do que apenas esfregar a matriz RAID para detectar qualquer bit rot (que não informa se os dados fazem algum sentido, apenas que foram escritos corretamente pelo controlador RAID).
A redundância do ZFS (RAIDZ, espelhamento, ...) tem a vantagem de que os locais de disco não utilizados não precisam ser verificados quanto à consistência durante as scrubs; somente os dados reais são verificados durante o scrubs, pois as ferramentas percorrem a cadeia de blocos de alocação. Isso é o mesmo que com um pool não redundante. Para RAID "regular", todos os dados (incluindo locais não utilizados no disco) devem ser verificados porque o controlador RAID (seja hardware ou software) não tem idéia de quais dados são realmente relevantes.
Usando RAIDZ2 vdevs, quaisquer duas unidades constituintes podem falhar antes que você corra o risco de perda real de dados devido a outra falha na unidade, já que você tem o valor de redundância de duas unidades. Isto é essencialmente o mesmo que o RAID6.
No ZFS, todos os dados, dados do usuário e metadados, são soma de verificação (exceto se você optar por não, mas é contra isso recomendado) e essas somas de verificação são usadas para confirmar que os dados não foram alterados por qualquer motivo. Novamente, se uma soma de verificação não corresponder ao valor esperado, os dados serão reconstruídos de forma transparente ou um erro de E / S será relatado. Se um erro de E / S for relatado ou um scrub identificar um arquivo com corrupção, você saberá que os dados nesse arquivo estão potencialmente corrompidos e podem restaurar esse arquivo específico a partir do backup; não há necessidade de uma restauração de matriz completa.
Simples, com paridade dupla, o RAID não protege você contra situações como, por exemplo, quando uma unidade falha e outra lê os dados incorretamente do disco. Suponha que uma unidade falhe e haja um único bit em qualquer lugar de qualquer uma das outras unidades: de repente, você tem corrupção não detectada e, a menos que esteja satisfeito com isso, precisará de uma maneira de, pelo menos, detectá-la. A maneira de mitigar esse risco é verificar cada bloco no disco e certificar-se de que a soma de verificação não possa ser corrompida junto com os dados (protegendo contra erros como gravações high-fly, gravações órfãs, gravações em locais incorretos no disco, etc.), é exatamente o que o ZFS faz contanto que a soma de verificação esteja ativada.
A única desvantagem real é que você não pode facilmente desenvolver um RAIDZ vdev adicionando dispositivos a ele. Existem soluções alternativas para isso, geralmente envolvendo coisas como arquivos esparsos como dispositivos em um vdev, e muitas vezes denominados "Eu não faria isso se fossem meus dados". Portanto, se você usar uma rota RAIDZ (independentemente de usar RAIDZ, RAIDZ2 ou RAIDZ3), será necessário decidir antecipadamente quantas unidades deseja em cada vdev. Embora o número de unidades em um vdev seja fixo, você pode aumentar gradualmente um vdev (certificando-se de permanecer dentro do limite de redundância do vdev) substituindo as unidades por outras de maior capacidade e permitindo uma conclusão completa resilver.