Adicionei acidentalmente um raidz1 incompatível a um pool existente. Sim, especifiquei o '-f' para fazer isso, mas esperava usar o '-f' por um motivo diferente e não estava prestando atenção.
Enfim... quão ruim é isso? Eu realmente só precisava de espaço extra na piscina e queria que esse espaço fosse redundante. A piscina fica assim:
NAME STATE READ WRITE CKSUM
pool_02c ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
c0t5000C500B4AA5681d0 ONLINE 0 0 0
c0t5000C500B4AA6A51d0 ONLINE 0 0 0
c0t5000C500B4AABF20d0 ONLINE 0 0 0
c0t5000C500B4AAA933d0 ONLINE 0 0 0
raidz1-1 ONLINE 0 0 0
c0t5000C500B0889E5Bd0 ONLINE 0 0 0
c0t5000C500B0BCFB13d0 ONLINE 0 0 0
c0t5000C500B09F0C54d0 ONLINE 0 0 0
Eu li outra pergunta sobre esse tipo de cenário e afirmava que "tanto o desempenho quanto a eficiência do espaço (ou seja: por meio de preenchimento não ideal) serão afetados", mas isso é um pouco vago e espero que alguém possa dar um pouco mais detalhe.
Do ponto de vista do uso do pool, os dados colocados nos discos no vdev raidz1-0 não são redundantes nesse vdev e os dados colocados no raidz1-1 são redundantes nesse vdev? E, se for esse o caso, o desempenho não estaria relacionado ao vdev específico?
Onde o preenchimento entra em jogo aqui e como isso afetaria a capacidade de armazenamento? ou seja. Isso faria com que mais espaço fosse alocado, como para cada 1 milhão que escrevo, uso 1,2 milhões?
Não estou muito preocupado com o desempenho deste pool, mas como essa configuração afeta as velocidades de leitura/gravação? Eu esperaria que cada vdev funcionasse na velocidade de seus respectivos dispositivos. Então, como uma diferença de replicação do vdev afeta isso?
Para sua informação, isso está em um sistema Solaris 11.4. Eu tentei remover o vdev usando:
zpool remove pool_02c raidz1-1
mas recebo o erro:
cannot remove device(s): not enough space to migrate data
O que parece estranho, já que literalmente acabei de adicioná-lo e não escrevi nada no pool.
Estou bem convivendo com isso, pois parece ter me dado o espaço que eu esperava, mas só quero entender melhor o diabo com quem estarei convivendo.
Resposta curta: embora um pouco abaixo do ideal, o layout do seu pool não deixa a desejar - é uma configuração legítima.
Resposta longa: RAIDZ vdev é atípico na forma como armazena dados em comparação com uma matriz RAID tradicional. Em um RAIDZ vdev, algum espaço pode ser perdido devido a a) preenchimento e b) largura de faixa dinâmica. Sugiro que você leia (várias vezes, se necessário) este artigo muito útil . De qualquer forma, as duas lições são:
a alocação acontece na
ashift * (redundancy+1)granularidade (ou seja: para umashift=12vdev RAIDZ, a granularidade de alocação será de blocos de 4K * (1 + 1). A alocação de 1, 3 ou 5 blocos não é possível; em vez disso, 2, 4 ou 6 serão alocados. Isso é interessante interação comrecordsize: como exemplo, para o caso extremo de todas as gravações de bloco de 4K, RAIDZ1 tem a mesma eficiência de espaço de vdevs espelhados (ou seja: 1 dado + 1 bloco de paridade)o tamanho da faixa é dinâmico, o que significa que para um único
recordsizebloco de dados haverá pelo menos, e possivelmente muitos (dependendo do vdev com), bloco de paridade. Isso significa que a interseção entre o tamanho máximo da faixa dinâmica (recordsize / ashift), o tamanho do arquivo e a largura do vdev fará com que uma quantidade variável de blocos de paridade diferentes sejam gravadosDevido ao ponto 2 acima, larguras de vdev desiguais podem levar a diferentes eficiências de espaço para os dois vdevs.
No entanto, você deve evitar colocar muito peso neste tipo de cálculo: habilitar a compactação alterará o tamanho efetivo da alocação física de uma maneira que quase sempre superará os pontos ideais de eficiência de espaço, conforme descrito pelas regras acima.
Portanto, se você tivesse 3 (e apenas 3) discos para adicionar a um vdev RAIDZ, você fez a coisa certa. Dito isto, tenha cuidado ao usar
-fSobre a remoção do vdev, não posso comentar porque não sei como o Solaris consegue isso.