Parece que isso foi corrigido no 11.0-RELEASE: link
Eu acho que eles não consideraram digno de uma porta de volta para 10.3-RELEASE-p22. : (
Ao tentar substituir um disco em um zpool em um sistema FreeBSD 10.3-RELEASE-p20 ontem, os sistemas de arquivos zfs pararam de responder após a emissão do comando zpool detach srv gpt/d0 . O servidor atua como um servidor NFS, um servidor WebDAV e um destino iSCSI e, após a execução de zpool detach , todos os clientes iSCSI começaram a ter tempos limites.
Isso aparentemente fez com que todo o subsistema ZFS fosse bloqueado. zpool status ou qualquer outro comando simplesmente travaria e não produziria nenhuma saída. Não havia nada exibido em dmesg e top não mostrava nenhum processo consumindo uma grande quantidade de CPU. No final, não conseguimos encontrar nenhuma solução e fomos forçados a reinicializar o sistema (inclusive usando uma reinicialização por hardware, porque uma reinicialização suave falhou ao reiniciar o sistema após a interrupção de todos os serviços) para obter os alvos iSCSI novamente on-line.
O que causa esta situação e como podemos evitá-la? Como podemos impedir que zpool detach seja interrompido ao substituir um dispositivo em um pool do ZFS no FreeBSD?
Parece que isso foi corrigido no 11.0-RELEASE: link
Eu acho que eles não consideraram digno de uma porta de volta para 10.3-RELEASE-p22. : (
Não sei ao certo por que isso acontece, mas descobrimos que esse problema estava relacionado a ter o Autoexpand do ZFS ativado no pool. Definindo autoexpand=off usando:
zpool set autoexpand=off srv
Nos permitiu desconectar e substituir outros dispositivos sem zpool detach pendurados da mesma maneira.
Ainda estou interessado em saber mais sobre esse modo de falha, mas respondi a minha própria pergunta na esperança de compartilhar o conhecimento de que a desativação da autoexpand pode resolver esse problema.