Com base na sua pergunta e nos comentários abaixo, você está perguntando se é uma boa ideia ter um pool dividido entre dois discos de tamanhos desiguais. A resposta curta é que não há nada intrinsecamente problemático nisso:
- Sua carga de trabalho não é crítica para o desempenho. Se estiver, use um tipo de disco uniforme em todo o pool. Caso contrário, os discos podem ter características de desempenho diferentes, o que pode criar problemas de desempenho muito sutis, que são difíceis de rastrear. (Por exemplo, digamos que você tenha dois discos de 10K RPM feitos pelo mesmo fornecedor no mesmo ano, um que seja 1TB e outro que seja de 2TB. Não tem problema, certo? Infelizmente, nenhum deles vai conseguir ~ duas vezes a taxa de transferência, embora o IOPS máximo seja o mesmo entre as unidades.
- Você está bem sem redundância adicional. Observe que, em qualquer situação de distribuição, você está aumentando a probabilidade de perder todos seus dados, porque você passou da probabilidade de um disco falhando, para a probabilidade de qualquer disco A ou disco B (ou ambos) falharem. Mesmo com o ZFS mantendo várias cópias de metadados, com uma metade aleatória dos dados faltando, você terá dificuldades para recuperar muitos arquivos completos / utilizáveis do seu pool.
Dito isto, ainda há maneiras imprudentes de configurar isso. Se um dos discos for um SSD e o outro for um HDD, o striping vai arruinar os ganhos de desempenho obtidos com o uso de um SSD e provavelmente o deixará muito triste. Nessa situação, recomendo também:
- Use o HDD maior como o "disco de dados principal" e divida o SSD em duas partições: uma partição grande usada como um dispositivo L2ARC (
cache) para acelerar as leituras de dados lidos freqüentemente, e uma pequena partição usada como um dispositivo ZIL (log) para acelerar as latências de gravação síncrona. Essa solução é boa porque armazenará automaticamente as coisas mais benéficas no SSD, então você não precisa pensar muito sobre balancear isso. Além disso, você perderá apenas todos seus dados se perder o HDD nesse caso (você poderá perder até alguns segundos de gravações se o SSD morrer, mas isso é muito melhor do que todos os seus dados, como no caso listrado acima). - Criando um pool separado para cada disco, e mantendo manualmente o material que você quer que seja rápido (SO, executáveis, bibliotecas, swap, etc) no SSD, e coisas que estão ok sendo lentas (filmes, álbuns de fotos, etc.) o disco rígido. Isso é melhor se a máquina for reinicializada com freqüência, porque os dados armazenados em cache no L2ARC não persistem durante as reinicializações. (Esta é uma grande fraqueza na história atual do L2ARC para computadores pessoais IMO, mas está sendo ativamente trabalhada.) Do ponto de vista de redundância, você obviamente só perde o material que estava no disco que falhou.
—- Edite já que esses discos são virtualizados —-
Como esta é uma VM, a menos que você tenha especificado parâmetros especiais para o desempenho dos discos, nenhum dos critérios de desempenho / redundância acima deve impedir que você crie o pool com dois tamanhos de disco incompatíveis. No entanto, será muito mais fácil gerenciá-lo se você usar sua plataforma de virtualização para redimensionar o disco original para a soma dos tamanhos de disco propostos. Para usar esse espaço adicional dentro do guest, você terá que executar zpool online -e <pool> <disk> , e como isso é o ZoL, você pode ter que corrigir sua tabela de partições primeiro, como nas instruções aqui .
Você deve preferir essa abordagem por causa da facilidade de gerenciamento, mas uma desvantagem muito pequena é que, quando você redimensiona, o ZFS não pode alterar seu tamanho de metaslab. Metaslabs são uma estrutura de dados interna usada para alocação de espaço em disco e, até muito recentemente, o ZFS sempre criava 200 deles por disco, independentemente do tamanho do disco (há trabalhos em andamento para melhorar isso). Portanto, quando você aumenta o tamanho do disco de muito pequeno para muito grande, pode acabar com um número muito alto de metaslabs, que usa um pouco mais de RAM e um pouco mais de espaço em disco. Isso não é perceptível, a menos que o tamanho do disco mude drasticamente (como 10G - > 1T) e, mesmo assim, somente quando você estiver empurrando sua máquina para o limite de desempenho. Geralmente, o impacto no desempenho pode ser contornado, dando à sua VM um pouco mais de RAM.