Foi realmente apoiado em um canto com isso. Acabaram achatando o pool e restaurando arquivos do backup no FreeNAS 8.
Parece muito mais estável até agora - o mais recente sistema operacional x64, 4 GB de RAM, provavelmente contribuindo.
Dado meu RAIDZ1 de quatro discos, um disco tornou-se fisicamente barulhento, não produzindo erros ainda, mas também não parece sadio. Então eu escolhi substituí-lo preventivamente.
Eu fiz:
zpool offline tank0 ad6
Desligue, remova e substitua o disco
zpool replace tank0 ad6 ad6
que paira para sempre.
zpool status também trava para sempre, assim como zpool history .
Se eu reiniciar a máquina com o disco removido, tudo funciona bem, no modo degradado, como esperado.
O que eu faço agora? Preocupado porque meus dados agora estão vulneráveis a uma única falha no disco.
OS é o FreeBSD 7.3-RELEASE-p1 - a.k.a. FreeNAS 7.0.2.5226
Acabei de tentar a mesma operação em uma VM, embora o FreeBSD 7.3-RELEASE-p7 (FreeNAS 0.7.2.8191, versão ligeiramente posterior) - funcione perfeitamente. Tentando com a versão mais antiga do FreeNAS eu posso encontrar agora (7.0.2.5799) e será atualizado mais tarde.
Além disso, zpool replace não requer uso de sistema de arquivos? Existe a possibilidade de que outro daemon no NAS esteja usando o sistema de arquivos. Eu assumo que isso seria OK, mas isso pode ser errado.
Atualização, 2012-01-10
Eu inicializei a máquina com FreeNAS 8 e fiz o zpool replace - que começou, e imediatamente comecei a jogar pilhas de erros de corrupção de dados e panes de kernel - apesar de uma limpeza semanal do conjunto nunca encontrando problemas. Eu não acho que fiz nada estúpido como dizer para substituir o disco errado. Eu imediatamente emiti shutdown -h , pois sei que os dados estavam bem.
De qualquer forma, agora tenho um pool degradado, preso em um estado em que a substituição está suspensa, e estou copiando meus dados para uma unidade externa de 3TB, comprada com grandes custos, para que eu possa destruir o pool e começar de novo. Felizmente, os dados parecem bem - por acaso eu tenho md5sums de cerca de 100GB dos arquivos, que até agora parecem estar intactos, e consegui recuperar tudo o que é verdadeiramente insubstituível.
Agora estou esperando mais RAM chegar, pois o FreeNAS 8 mantém o panicing com erros kmem_max muito pequenos, que não parecem ser capazes de sintonizar, e a máquina foi restringida a RAM (1 GB de RAM para um RAIDZ1 de 4 TB ).
A lição difícil aprendeu sobre backups, mas também a confiança no ZFS / FreeNAS / FreeBSD realmente bateu.
ATUALIZAÇÃO 13/1/12
Bem, meus dados parecem ter um backup seguro agora.
zpool status -v trava mesmo com o failmode configurado para continuar. Aqui está a saída do zpool status, com o novo disco conectado (ada1)
pool: tank0
state: DEGRADED
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the entire pool
from backup.
see: http://www.sun.com/msg/ZFS-8000-8A
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank0 DEGRADED 0 0 0
raidz1 DEGRADED 0 0 0
ada2 ONLINE 0 0 0
ada3 ONLINE 0 0 0
ada0 ONLINE 0 0 0
replacing DEGRADED 0 0 3.17K
6540253751212815210 UNAVAIL 0 0 0 was /dev/ada3/old
ada1 ONLINE 0 0 0
errors: 3130 data errors, use '-v' for a list
Com o disco antigo conectado em vez do novo, o ZFS não importará o pool e zfs status diz:
tank0 UNAVAIL insufficient replicas
raidz1 FAULTED corrupted data
ada2 ONLINE
ada3 ONLINE
ada0 FAULTED corrupted data
replacing UNAVAIL insufficient replicas
ada1 FAULTED corrupted data
ada1 FAULTED corrupted data
Não vejo por que ada0 deveria ser FAULTED com o novo disco (ada1) conectado, mas ONLINE com o disco antigo conectado? Eu não vejo como o ada0 está relacionado.
Vamos tentar recuperar esse pool como um exercício de aprendizado.
Não sou um guru do ZFS, mas vou tentar: Parece que o subsistema do ZFS ainda está tentando acessar a unidade com falha e está pendurado por algum motivo. Tente definir o valor failmode do pool como continue ( zpool set failmode=continue ) e veja se isso faz com que o hang away desapareça e que você descubra o que está acontecendo.
(Observe que isso não é uma correção: o sistema ainda não consegue acessar uma unidade que acha que deve ser capaz de acessar, apenas informando para retornar um erro e continuar em vez de bloqueá-lo até que uma resposta seja recebida .)
Recentemente, tive uma situação que parece semelhante, embora eu não estivesse com problemas, não consegui substituir a unidade com falha. Claro, eu estava em um ambiente totalmente diferente: Linux com fusível ZFS. No entanto, ao contrário de você, eu não estava sendo informado de que havia sofrido corrupção de dados, estava vendo:
state: DEGRADED
status: One or more devices could not be opened. Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
see: http://www.sun.com/msg/ZFS-8000-2Q
[...]
disk/by-id/ata-Hitachi_HDS722020ALA330_JK1105B8GNNADX-part4 UNAVAIL 0 0 0 cannot open
Agora, antes de prosseguir, é importante perceber que nenhum dos dados desse pool foi insubstituível, que foi feito backup de tudo ou backups de outros sistemas. Se você não tiver bons backups desses dados, provavelmente vai querer parar nesse ponto e fazer cópias brutas dos discos antes de fazer qualquer outra coisa, caso isso piore.
O que acabei fazendo que funcionou foi isso.
Primeiro, eu exportei o pool com "zfs export POOLNAME". Eu reiniciei e fiz um "zfs import POOLNAME".
Agora, quando fiz um "zpool status", recebi este:
state: DEGRADED
[...]
12640132412556728613 UNAVAIL 0 0 0 was /dev/disk/by-id/ata-Hitachi_HDS722020ALA330_JK1105B8GNNADX-part4
Agora eu consegui usar o número acima para substituir o disco usando:
zpool replace POOLNAME 12640132412556728613 /dev/DEVILCENAME
Agora ele apareceu substituindo a unidade em "zpool status":
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scrub: resilver in progress for 0h0m, 0.00% done, 282h43m to go
"apenas" levou cerca de 48 horas para ser executado, não o estimado acima de 282. : -)