On 09/24/2015 08:41 AM, Victório wrote:
Em 23-09-2015 18:03, victorio@felipe.center escreveu:
Em 2015-09-23 17:37, Giovanni Tirloni escreveu:
On 09/23/2015 05:13 PM, victorio@felipe.center wrote:
solaris assert rs == NULL, file:
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/range_tree.c,
line 186
Em single-mode, por favor rode o comando `zdb -b -c -A dados` para ter
mais detalhes do que pode estar errado.
Giovanni
Giovanni, estou rodando o comando.
Deu alguns erros relacionados à rs_start e rs_end, que estão no código do zfs
no range_tree.c, mas tá executando.
Assim que terminar eu reporto.
Obrigado.
Bom dia. O zdb terminou de rodar e apresentou:
block tranversal size 950842077968 != alloc 946547740672 (leaked -4294967296)
bp count: 11172286
ganged count: 0
bp logical: 950780091392 avg: 85101
bp physical: 937320184320 avg: 83896 compression: 1.01
bp allocated: 950842707968 avg: 85107 compression: 1.00
bp deduped: 0 ref>1: 0 deduplication: 1.00
SPA allocated: 946547740672 used: 47.50%
additional, no-pointer bps of type 0: 65760
Dittoed blocks on same vdev: 1015135
Contudo um simples zpool list dados ainda dá o mesmo panic.
O ZFS esta tentando fazer a alocação de um bloco que já está alocado. Parece que
os metadados do seu pool estão corrompidos.
Como o Danilo mencionou, pode ser que esteja havendo um conflito com a GPT.
Porém, o ZFS grava os superblocos muitas vezes no disco. Tanto é que você
provavelmente está conseguindo fazer o zpool import, certo? O ZFS identifica que
existe um pool ali e acessa, mas na hora de manipular a arvore binária, ele
encontra incosistências.
Sem ter um mirror para tentar um zpool scrub, minha única recomendação destruir
o pool, zerar o disco, recriar o pool e voltar os backups :(
Giovanni
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
