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 zpool detach srv gpt/d0comando. O servidor atua como um servidor NFS, servidor WebDAV e destino iSCSI e, após a execução, zpool detachtodos os clientes iSCSI começaram a apresentar tempos limite.
Isso aparentemente causou o travamento de todo o subsistema ZFS. zpool statusou qualquer outro comando simplesmente travaria e não produziria nenhuma saída. Não havia nada aparecendo no dmesg, e topnã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 forçada porque uma reinicialização suave falhou ao reiniciar o sistema após interromper todos os serviços) para colocar os destinos iSCSI novamente online.
O que causa essa situação e como podemos evitá-la? Como podemos evitar zpool detachtravamentos ao substituir um dispositivo em um pool ZFS no FreeBSD?
Não tenho certeza por que isso acontece, mas descobrimos que esse problema estava relacionado a ter o ZFS Autoexpand ativado no pool. Configurando
autoexpand=offusando:Permitiu-nos desconectar e substituir outros dispositivos sem
zpool detachtravar da mesma maneira.Ainda estou interessado em entender mais sobre esse modo de falha, mas estava respondendo minha própria pergunta na esperança de compartilhar o conhecimento de que desabilitar a expansão automática pode resolver esse problema.
Parece que isso foi corrigido em 11.0-RELEASE: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216881
Eu acho que eles não consideraram digno de uma porta traseira para 10.3-RELEASE-p22. :(