Versão resumida:
Você tem que fazer o contrário: substituir o disco do pool com falha (com um novo disco ou consigo mesmo) e, depois disso, desanexar o disco sobressalente do pool (para que fique disponível para todos os vdevs). Presumo que o sobressalente esteja ocupado desde que o disco usado para substituição não seja substituído. Desanexar este disco ou outro disco só piora a situação.
Além disso, eu me lembro que o ZoL não tem anexar / desanexar automaticamente as peças de reposição, dependendo dos eventos, você tem que criar um script próprio ou usar algo como daemon de eventos do ZFS .
Versão longa:
Com relação ao seu comentário subsequente
If C disk is FAULTED, ok let's replace it then detach it. But It scew up my pool, because zpool didnt remember I used to have a C disk in the mirror-1 :/
Isso depende de como você o vê. Se você desanexar um disco de um espelho, isso não será mais relevante. Pode estar com defeito, pode ser usado em outro sistema, pode ser substituído sob garantia do fabricante. Seja o que for feito com isso, sua piscina não se importa.
Se você simplesmente desanexar o disco, ele será degradado; se você fornecer outro disco (de reposição automática, reposição manual ou substituição totalmente manual), este disco assumirá o papel do disco antigo (daí o termo replace , o novo disco substitui totalmente o disco antigo em sua posição e deveres).
Se desejar, você pode adicionar o disco desanexado de volta ao pool, por exemplo, como sobressalente (para que a situação inicial seja invertida).
Como as peças de reposição funcionam nos sistemas ZFS
As peças de reposição só fazem sentido com a ativação automática. Os arrays de armazenamento ZFS, conforme projetados pela Sun, tinham muitos discos semelhantes; as quantidades de 18 a 48 discos não eram incomuns. Eles consistiam em vários vdevs, por exemplo, 4 x RAID Z2 para um sistema de 24 discos. Além disso, eles foram gerenciados por um administrador dedicado, mas ninguém pode trabalhar 24/7. Portanto, eles precisavam de algo como primeira resposta e tinham que trabalhar em todos os vdevs, porque qualquer disco pode falhar a qualquer momento.
Portanto, se tarde da noite um disco em seu segundo vdev falhar, o sistema pegará automaticamente uma das duas peças configuradas e substituirá o disco com falha, de modo que o pool funcione normalmente (mesmo desempenho para clientes que usam um site cujo banco de dados executa, por exemplo). De manhã, o administrador lê o relatório da falha e soluciona a causa:
- Se o disco tiver morrido, ele poderá substituí-lo por um disco de substituição na mesma bandeja, deixá-lo resilver e, em seguida, o hotspare será automaticamente retirado para o trabalho sobressalente, observando outro disco morto no qual ele possa fazer a primeira resposta. / li>
- Se nenhum disco de substituição estiver disponível, ele pode até mesmo disponibilizar o novo disco de dados, reduzindo o número de sobressalentes temporariamente em 1 (até que outro disco de substituição seja enviado, que se tornará o novo sobressalente).
- Se fosse apenas um erro do controlador ao descartar o disco, ele poderia até substituí-lo por si mesmo, acionando a mesma renovação de reposição que no primeiro caso.
Se você pensar sobre isso da maneira que os engenheiros projetaram para o cenário de uso antecipado mais comum, ele fará muito mais sentido. Isso não significa que você tenha que fazer exatamente como descrito, pode ser apenas uma razão para o comportamento.
Respostas às suas perguntas
Why replacing the C disk is not enough to rebuild a full pool? As explained on the oracle blog and here too I was expecting that I do not have to detach the disk for zfs to rebuild the pool properly (and it's far better to keep in the zpool status traces of the unplugged disk, for maintening convenience)
Como visto acima, você pode substituir o disco do pool por outro ou por si (o sobressalente estará livre e continuará funcionando como reserva) ou você poderá desanexar o disco do pool, enquanto o sobressalente assumirá permanentemente o papel de um pool disco e você tem que adicionar outro sobressalente à mão com zpool add poolname spare diskname (que pode ser o disco desanexado ou um novo).
Why zpool keep telling me that spares disks are "busy" (they are truly not)?
Eu suponho que foi por causa do excelente IO. Isso explicaria por que demorou um pouco para concluir a operação.
See below: how can I automatically get my spare disk back?
- Ativar substituição sobressalente automática (padrão no Solaris / illumos, pouco incômodo no Linux)
- Substitua o disco do conjunto com falha por
zpool replace(em vez de desanexá-lo). A etapa de desanexação é necessária apenas para o disco reserva após a substituição do disco do conjunto e se você não tiver gerenciamento automático (o que não faz sentido em meus olhos, exceto para layouts de pool específicos e situações administrativas).