Capítulo 11 Solução de problemas e conjunto de recuperação do Oracle Solaris ZFS
Este capítulo descreve como identificar e recuperar a partir de falhas do ZFS. Também são fornecidas informações sobre como evitar tais falhas.
Este capítulo traz as seguintes seções:
Identificando falhas do ZFS
Por ser uma combinação de um sistema de arquivos e um gerenciador de volumes, o ZFS pode exibir diferentes falhas. Este capítulo começa delineando as várias falhas e, em seguida, discute como identificá-las em um sistema em execução. E finalmente termina tratando o tema de como reparar os problemas. O ZFS pode encontrar três tipos básicos de erros:
Observe que um único pool pode sofrer os três tipos de erros, de modo que o procedimento completo de reparação implica em encontrar e corrigir o erro, passar para o próximo erro, e assim por diante.
Ausência de dispositivos em um pool de armazenamento do ZFS
Se um dispositivo for completamente removido do sistema, o ZFS detecta que o dispositivo não pode ser aberto e o coloca no estado REMOVIDO. Dependendo do nível de replicação dos dados do conjunto, essa remoção pode ou não fazer com que todo o conjunto se torne indisponível. Se, em um dispositivo RAID-Z ou espelhado, um disco for removido, o pool continua acessível. Um conjunto pode se tornar FAULTED, o que significa que nenhum dado é acessível até que o dispositivo seja desanexado, sob as condições a seguir:
-
Se todos os componentes de um espelho são removidos
-
Se mais de um dispositivo em um dispositivo (raidz1) RAID-Z é removido
-
Se o dispositivo de nível superior é removido em uma configuração de disco único
Dispositivos danificados em um pool de armazenamento do ZFS
O termo “danificado” abrange uma ampla variedade de possíveis erros. Os exemplos incluem o seguinte:
-
Erros transitórios de E/S devido a disco ou controlador defeituosos
-
Corrupção de dados em disco devido a raios cósmicos
-
Erros de driver resultando em transferência de dados de ou para locais incorretos
-
Um usuário substitui porções do dispositivo físico por acidente
Em alguns casos, estes erros são transitórios, como um erro de E/S aleatório durante problemas com o controlador. Em outros casos, o problema pode ser permanente, como a corrupção em disco. Ainda assim, se o problema for permanente, isso não significa necessariamente que o erro ocorrerá novamente. Por exemplo, se um administrador substitui acidentalmente parte de um disco, e nenhum tipo de falha de hardware ocorre, o dispositivo não precisa ser trocado. Identificar exatamente o problema com o dispositivo não é uma tarefa fácil, por isso esse tema é abordado mais detalhadamente em uma seção posterior.
Dados corrompidos do ZFS
A corrupção de dados ocorre quando um ou mais erros no dispositivo (indicando um ou mais dispositivos ausentes ou danificados) afetam o dispositivo virtual de nível superior. Por exemplo, a metade de um espelho pode sofrer milhares de erros de dispositivo sem jamais causar corrupção de dados. Haverá corrupção de dados se for encontrado um erro no outro lado do espelho no mesmo exato local.
A corrupção de dados é sempre permanente e requer cuidados especiais durante a reparação. Mesmo que os dispositivos subjacentes forem reparados ou substituídos, os dados originais não poderão ser recuperados. Frequentemente, esse tipo de situação requer a recuperação dos dados a partir de backups. Os erros dos dados são registrados à medida que vão sendo encontrados e podem ser controlados através de scrubbing rotineira do conjunto, como explicado na seção seguinte. Quando um bloco corrompido é removido, o próximo ciclo de limpeza reconhece que a corrupção já não existe e remove qualquer vestígio de erro do sistema.
Verificando a integridade do sistema de arquivos ZFS
Não existe o utilitário fsck equivalente para o ZFS. Esse utilitário tem tradicionalmente servido a dois propósitos, ao reparo e à validação do sistema de arquivos.
Reparo de sistema de arquivos
Com os sistemas de arquivos tradicionais, a forma como os dados são gravados está inerentemente vulnerável a falhas inesperadas, provocando inconsistências de dados. Como um sistema de arquivos tradicional não é transacional, blocos não referenciados, contagens ruins de link ou outras estruturas de sistema de arquivos inconsistentes são possíveis. A adição de registros de ações resolve alguns destes problemas, porém pode trazer outros problemas quando o registro não puder ser revertido. A única forma para dados inconsistentes existirem no disco em uma configuração ZFS é através de falha do hardware (nesse caso o conjunto deve possuir redundância) ou quando um erro existir no software ZFS.
O utilitário fsck repara problemas conhecidos específicos para sistemas de arquivos UFS. A maioria dos problemas do conjunto de armazenamento do ZFS são relacionados com falhas de hardware ou falhas de energia. Muitos problemas podem ser evitados através da utilização de conjuntos redundantes. Se o conjunto for danificado por falhas de hardware ou queda de energia, consulte Reparando o dano de todo o pool de armazenamento do ZFS.
Se o conjunto não for redundante, haverá sempre a possibilidade de que a corrupção do sistema de arquivos torne alguns ou todos os dados inacessíveis.
Validação do sistema de arquivos
Além de efetuar a reparação do sistemas de arquivos, o utilitário fsck valida que os dados em disco não apresentam problemas. Tradicionalmente, essa tarefa requer a desmontagem do sistema de arquivos e a execução do utilitário fsck, levando o sistema possivelmente para o modo de usuário único no processo. Este quadro tem como resultado um tempo de inatividade proporcional ao tamanho do sistema de arquivos que está sendo verificado. Em vez de exigir um utilitário explícito para efetuar a verificação necessária, o ZFS fornece um mecanismo para efetuar verificações rotineiras de todos as inconsistências. Esse recurso, conhecido como scrubbing, é utilizado, geralmente, na memória e em outros sistemas como um método de detecção e prevenção de erros, antes que estes provoquem falha de hardware ou de software.
Controlando o scrubbing de dados do ZFS
Sempre que o ZFS encontrar um erro através de scrubbing ou ao acessar um arquivo por demanda, o erro é registrado internamente para que você possa ter uma visão geral rápida de todos os erros conhecidos no conjunto.
Scrubbing explícito de dados do ZFS
A forma mais simples de verificar a integridade dos dados é iniciar um scrubbing explícito de todos os dados do conjunto. Esta operação percorre todos os dados do pool uma vez e comprova que todos os blocos possam ser lidos. O scrubbing se desenvolve tão rápido quanto os dispositivos permitam, sem bem que a prioridade de qualquer E/S é menor que a prioridade dada às operações normais. Essa operação pode impactar negativamente o desempenho, embora os dados do conjunto devam permanecer utilizáveis e um pouco receptivos enquanto o scrubbing ocorrer. Para iniciar um scrubbing explícito, use o comando zpool scrub. Por exemplo:
# zpool scrub tank |
O status da operação de scrubbing atual pode ser exibido utilizando o comando zpool status. Por exemplo:
# zpool status -v tank
pool: tank
state: ONLINE
scrub: scrub completed after 0h7m with 0 errors on Tue Tue Feb 2 12:54:00 2010
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c1t0d0 ONLINE 0 0 0
c1t1d0 ONLINE 0 0 0
errors: No known data errors
|
Somente uma operação de scrubbing ativa por conjunto pode ocorrer por vez.
É possível parar uma operação de scrubbing em andamento com a opção -s. Por exemplo:
# zpool scrub -s tank |
Na maioria dos casos, as operações de scrubbing devem chegar até o final para garantir a integridade dos dados. Interrompa uma operação de scrubbing de acordo com os seus próprios critérios se a performance do sistema é impactada pela operação.
Efetuar scrubbing de rotina garante E/S contínua para todos os discos do sistema. Scrubbing rotineiros apresentam a desvantagem de não permitir que o gerenciamento de energia coloque os discos inativos no modo de energia baixa. Se o sistema estiver geralmente realizando E/S sem parar ou se o consumo de energia não for uma preocupação, então esta questão pode ser ignorada sem perigo.
Para obter mais informações sobre a interpretação da saída zpool status, consulte Consultando status de pool de armazenamento do ZFS.
Scrubbing e resilvering de dados do ZFS
Quando um dispositivo é substituído, inicia-se uma operação de resilvering para mover os dados provenientes de cópias boas para o novo dispositivo. Esta ação é uma forma de scrubbing de disco. Portanto, somente uma dessas ações pode ocorrer em um dado momento no conjunto. Se uma operação de scrubbing estiver em andamento, a operação de resilvering suspende o scrubbing atual e o reinicia depois que o resilvering for concluído.
Para obter mais informações sobre o resilvering, consulte Exibindo o status do resilvering.
Resolvendo problemas com o ZFS
As seções a seguir descrevem como identificar e resolver problemas nos sistemas de arquivos ou nos conjuntos de armazenamento ZFS:
Você pode usar os seguintes recursos para identificar problemas na configuração do seu ZFS:
-
O conjunto de armazenamento do ZFS detalhado pode ser exibido através da utilização do comando zpool status.
-
As falhas do conjunto e do dispositivo são relatadas através de mensagens de diagnóstico ZFS/FMA.
-
Os comandos do ZFS anteriores que modificaram as informações de estado do conjunto podem ser exibidos através da utilização do comando zpool history.
A maioria das soluções de problemas do ZFS envolvem o comando zpool status. Esse comando analisa as diferentes falhas no sistema e identifica o problema mais grave, apresentando-lhe ações sugeridas e um link a um artigo com mais informações. Observe que o comando identifica somente um único problema com o conjunto, embora existam vários problemas. Por exemplo, erros de dados corrompidos geralmente implicam que um dos dispositivos falhou, mas substituir os dispositivos falhos não deve resolver todos os problemas de corrupção de dados.
Além disso, um diagnóstico do ZFS gera diagnósticos e relata falhas de conjuntos e de dispositivos. Soma de verificação, E/S, dispositivo, e erros de conjuntos associados com essas falhas também são reportadas. As falhas do ZFS, conforme relatadas por fmd, são exibidas no console, bem como no arquivo de mensagens do sistema. Na maioria dos casos, a mensagem fmd leva você ao comando zpool status para obter instruções de recuperação adicionais.
O processo básico de recuperação realiza-se da seguinte forma:
-
Se for apropriado, utilize o comando zpool history para identificar os comandos do ZFS que precedem cenário do erro. Por exemplo:
# zpool history tank History for 'tank': 2010-07-15.12:06:50 zpool create tank mirror c0t1d0 c0t2d0 c0t3d0 2010-07-15.12:06:58 zfs create tank/erick 2010-07-15.12:07:01 zfs set checksum=off tank/erick
Nessa saída, note que as somas de verificação estão desativadas no sistema de arquivos tank/erick . Esta configuração não é recomendável.
-
Identifique os erros através das mensagens fmd exibidas no console do sistema ou nos arquivos /var/adm/messages.
-
Localize as instruções de reparação adicionais através da utilização do comando zpool status -x.
-
Reparar falhas envolve as etapas a seguir:
-
Substitua o dispositivo defeituoso ou ausente e o coloque on-line.
-
Restaure a configuração defeituosa ou os dados corrompidos a partir de um backup.
-
Verifique a recuperação utilizando o comando zpool status - x.
-
Efetue backup da configuração restaurada, se aplicável.
-
Essa seção descreve como interpretar a saída de zpool status a fim de diagnosticar os tipos de falhas que podem ocorrer. Embora a maioria do trabalho seja efetuado automaticamente pelo comando, é importante entender exatamente que problemas estão sendo identificados a fim de diagnosticar o tipo da falha. Seções subsequentes descrevem como reparar vários problemas que você pode encontrar.
Determinando se há problemas em um conjunto de armazenamento do ZFS
A forma mais fácil de determinar se há problemas conhecidos no sistema é utilizar o comando zpool status -x. . Esse comando descreve somente os conjuntos que apresentam problemas. Se não há nenhum conjunto defeituoso no sistema, então o comando exibe o seguinte:
# zpool status -x all pools are healthy |
Sem o sinalizador -x, o comando exibe o status completo de todos os pools (ou do pool solicitado, se especificado na linha de comando), mesmo que os pools não apresentem falhas.
Para obter mais informações sobre opções de linha de comando para o comando zpool status, consulte Consultando status de pool de armazenamento do ZFS.
Revisando a saída de zpool status
A saída de zpool status completa se assemelha ao ilustrado abaixo:
# zpool status tank
# zpool status tank
pool: tank
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
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
c1t0d0 ONLINE 0 0 0
c1t1d0 UNAVAIL 0 0 0 cannot open
errors: No known data errors
|
Essa saída é descrita a seguir:
Informações gerais sobre o status do pool
Essa seção na saída de zpool status contém os campos a seguir, alguns dos quais são exibidos somente para os conjuntos que apresentam problemas:
- pool
-
Identifique o nome do conjunto.
- state
-
Indique a integridade atual do conjunto. Esta informação se refere somente a capacidade que o pool apresenta de oferecer o nível de replicação necessário.
- status
-
Descreva o que há de errado com o conjunto. Esse campo é omitido se nenhum erro for encontrado.
- action
-
Uma ação recomendada para a reparação de erros. Esse campo é omitido se nenhum erro for encontrado.
- see
-
Referência a um artigo conhecido com informações sobre a reparação. Os artigos on-line são atualizados com mais frequência do que guias podem ser atualizados. Então, sempre os referencie para o mais atualizado procedimento de reparação. Esse campo é omitido se nenhum erro for encontrado.
- scrub
-
Identifique o status atual da operação de scrub, que deve incluir a data e a hora de conclusão do último scrub realizado, um scrub em andamento ou se nenhum scrub foi solicitado.
- errors
-
Identifica erros de dados ou ausência de erros de dados conhecidos.
Informações sobre a configuração do pool
O campo config na saída zpool status descreve a configuração dos dispositivos no conjunto, bem como seu estado e quaisquer erros gerados a partir dos dispositivos. O estado pode ser um dos seguintes: ONLINE, FAULTED, DEGRADED, UNAVAIL ou OFFLINE. Se for exibido somente ONLINE, a tolerância a falhas do pool foi comprometida.
A segunda seção da saída de configuração exibe os erros de estatísticas. Estes erros estão divididos em três categorias:
-
READ: erros de E/S ocorridos durante uma solicitação de leitura
-
WRITE: erros de E/S ocorridos durante uma solicitação de gravação
-
CKSUM: erros de soma de verificação, significam que o dispositivo retornou dados corrompidos como resultado de uma requisição de leitura
Estes erros podem ser usados para determinar se o dano é permanente. Uma pequena quantidade de erros de E/S pode indicar uma interrupção temporária, enquanto que uma grande quantidade pode indicar um problema permanente com o dispositivo. Estes erros não correspondem necessariamente à corrupção de dados conforme interpretado pelos aplicativos. Se o dispositivo estiver em uma configuração redundante, os dispositivos podem exibir erros incorrigíveis, enquanto nenhum erro aparece no espelho ou no nível do dispositivo RAID-Z. Em tais casos, o ZFS recupera com sucesso os dados bons e tenta reabilitar dados danificados a partir das réplicas existentes.
Para mais informações sobre a interpretação desses erros, consulte Determinando o tipo de falha do dispositivo.
Finalmente, na última coluna da saída de zpool status se encontram informações adicionais auxiliares. Essas informações abrangem o campo estado, auxiliando em diagnósticos de falhas. Se um dispositivo apresenta o estado FAULTED, este campo indica se o dispositivo encontra-se inacessível ou se os dados do dispositivo estão corrompidos. Se o dispositivo estiver sendo submetido a um resilvering, este campo exibe o progresso atual.
Para mais informações sobre a monitoração do progresso de resilvering, consulte Exibindo o status do resilvering.
Status do scrubbing
A terceira seção de scrub da saída zpool status descreve o status atual de quaisquer operações de scrubbing explícitas. Se qualquer tipo de erro for detectado no sistema, estas informações serão diferentes, embora possam ser usadas para determinar a precisão do relatório de erro de corrupção de dados. Se o último scrubbing acabou de ser concluído, provavelmente nenhuma corrupção de dados conhecida foi encontrada.
Mensagens de finalização de scrub persistem através da reinicialização do sistema.
Para mais informações sobre o scrubbing de dados e como interpretar essas informações, consulte Verificando a integridade do sistema de arquivos ZFS.
Erros de corrupção de dados
O comando zpool status mostra também se os erros conhecidos estão associados ao pool. Esses erros podem ter sido encontrados durante o scrubbing de dados ou durante uma operação normal. O ZFS mantém um log persistente de todos os erros de dados associados ao conjunto. Este registro é alternado sempre que um scrubbing completo do sistema for concluído.
Os erros de corrupção de dados são sempre fatais. A presença de tais erros indica que como mínimo um aplicativo sofreu um erro de E/S devido a dados corrompidos dentro do pool. Os erros de dispositivo dentro de um pool redundante não têm como resultado a corrupção de dados e não são registrados como parte deste registro. Por padrão, somente o número de erros encontrado é exibido. Uma lista completa de erros e de suas condições específicas pode ser encontrada usando a opção -v do zpool status. Por exemplo:
# zpool status -v
pool: tank
state: UNAVAIL
status: One or more devices are faulted in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
see: http://www.sun.com/msg/ZFS-8000-HC
scrub: scrub completed after 0h0m with 0 errors on Tue Feb 2 13:08:42 2010
config:
NAME STATE READ WRITE CKSUM
tank UNAVAIL 0 0 0 insufficient replicas
c1t0d0 ONLINE 0 0 0
c1t1d0 UNAVAIL 4 1 0 cannot open
errors: Permanent errors have been detected in the following files:
/tank/data/aaa
/tank/data/bbb
/tank/data/ccc
|
Uma mensagem semelhante também é exibida pelo fmd no console do sistema e no arquivo /var/adm/messages. Estas mensagens também podem ser rastreadas através do comando fmdump.
Para obter mais informações sobre a interpretação dos erros de corrupção de dados, consulte Identificando o tipo de corrupção de dados.
Relatório de mensagens de erros do ZFS do sistema
Além de manter um rastreio persistente de erros dentro do conjunto, o ZFS exibe também mensagens syslog quando ocorrem eventos de interesse. As situações abaixo geram eventos para notificar o administrador:
-
Transição de estado do dispositivo – Se um dispositivo passa a ser FAULTED, o ZFS registra uma mensagem indicando que a tolerância a falhas do pool pode estar em risco. Uma mensagem semelhante é enviada se o dispositivo passar a ser on-line, restaurando a normalidade do pool.
-
Corrupção de dados – Se for detectado qualquer tipo de corrupção de dados, o ZFS registra uma mensagem descrevendo quando e onde a corrupção foi detectada. Esta mensagem é registrada somente na primeira vez que a corrupção é detectada. Os acessos subseqüentes não geram mensagens.
-
Falhas de conjunto e de dispositivos: se ocorrer uma falha de conjunto ou de dispositivo, o daemon do gerenciador de falhas relata esses erros através de mensagens syslog bem como o fmdump.
Se o ZFS detectar um erro de dispositivo e se recuperar automaticamente, não ocorre nenhuma notificação. Tais erros não representam uma falha na integridade dos dados ou de redundância do conjunto. São normalmente o resultado de um problema do driver acompanhado por seu próprio conjunto de mensagens de erro.
Reparando uma configuração do ZFS danificada
O ZFS mantém um cache de conjuntos ativos e de suas configurações no sistema de arquivos raiz. Se esse arquivo for corrompido ou, de alguma forma, perder a sincronia com a informações de configuração que está armazenado no disco, o conjunto não poderá mais ser aberto. O ZFS tenta evitar essa situação, embora sempre exista a possibilidade de haver corrupções arbitrárias dadas as qualidades do armazenamento subjacente. Esta situação resulta normalmente no desaparecimento de um pool do sistema quando tal pool deveria, na verdade, estar disponível. Essa situação também pode manifestar-se como uma configuração parcial com ausência de um número desconhecido de dispositivos virtuais de nível superior. Em ambos os casos, a configuração pode ser recuperada exportando o conjunto (se estiver visível) e importando-o novamente.
Para mais informações sobre a importação e exportação de conjuntos, consulte Migrando pools de armazenamento do ZFS.
Reparando um dispositivo faltando
Se um dispositivo não puder ser aberto, será exibido como UNAVAILABLE na saída zpool status. Esse status significa que o ZFS não pode abrir o dispositivo quando o conjunto foi acessado pela primeira vez ou que o dispositivo se tornou indisponível a partir desse momento. Se o dispositivo fizer com que o dispositivo virtual de nível superior não esteja disponível, então não será possível acessar nada no pool. Do contrário, a tolerância a falhas do pool pode ser comprometida. Em ambos os casos, o dispositivo precisa simplesmente ser reanexado ao sistema para recuperar a operação normal.
Por exemplo, uma mensagem do fmd semelhante à ilustrada abaixo deve ser vista depois de uma falha no dispositivo:
SUNW-MSG-ID: ZFS-8000-FD, TYPE: Fault, VER: 1, SEVERITY: Major EVENT-TIME: Thu Jun 24 10:42:36 PDT 2010 PLATFORM: SUNW,Sun-Fire-T200, CSN: -, HOSTNAME: neo2 SOURCE: zfs-diagnosis, REV: 1.0 EVENT-ID: a1fb66d0-cc51-cd14-a835-961c15696fcb DESC: The number of I/O errors associated with a ZFS device exceeded acceptable levels. Refer to http://sun.com/msg/ZFS-8000-FD for more information. AUTO-RESPONSE: The device has been offlined and marked as faulted. An attempt will be made to activate a hot spare if available. IMPACT: Fault tolerance of the pool may be compromised. REC-ACTION: Run 'zpool status -x' and replace the bad device. |
Para visualizar mais informações detalhadas sobre problemas e resoluções de dispositivos, utilize o comando zpool status -x. Por exemplo:
# zpool status -x
pool: tank
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
scrub: scrub completed after 0h0m with 0 errors on Tue Feb 2 13:15:20 2010
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
c1t0d0 ONLINE 0 0 0
c1t1d0 UNAVAIL 0 0 0 cannot open
errors: No known data errors
|
É possível observar nessa saída que o dispositivo c1t1d0 ausente não está funcionando. Se você determinar que o dispositivo é falho, substitua-o.
Depois, utilize o comando zpool online para colocar o dispositivo substituído on-line. Por exemplo:
# zpool online tank c1t1d0 |
Como uma última etapa, confirme que o conjunto com o dispositivo substituído está íntegro. Por exemplo:
# zpool status -x tank pool 'tank' is healthy |
Reanexando fisicamente um dispositivo
A forma como é realizada a reanexação de um dispositivo ausente depende do dispositivo em questão. Se o dispositivo for um drive anexado à rede, a conectividade deve ser restaurada. Se o dispositivo for um dispositivo USB ou outro tipo de mídia removível, deve ser reanexado ao sistema. Se o dispositivo for um disco local, um controlador pode ter falhado, de forma que tal dispositivo não está mais visível no sistema. Nesse caso, o controlador deve ser substituído no momento em que os discos estarão novamente disponíveis. Podem existir outros problemas que dependem do tipo de hardware e de sua configuração. Se uma unidade falhar e não estiver mais visível no sistema, o dispositivo deve ser tratado como um dispositivo danificado. Siga os procedimentos em Substituindo ou reparando um dispositivo modificado.
Notificando o ZFS da disponibilidade de um dispositivo
Depois que um dispositivo é reanexado ao sistema, o ZFS pode ou não detectar automaticamente sua disponibilidade. Se o conjunto já apresentava defeito anteriormente ou se o sistema tiver sido reinicializado como parte do procedimento anexar, então o ZFS reexamina todos os dispositivos ao tentar abrir o conjunto. Se o conjunto estava danificado e o dispositivo foi substituído enquanto o sistema estava em execução, é necessário notificar ao ZFS que o dispositivo está disponível e pronto para ser reaberto utilizando o comando zpool online. Por exemplo:
# zpool online tank c0t1d0 |
Para obter mais informações sobre como colocar dispositivos on-line, consulte Colocando um dispositivo on-line.
Substituindo ou reparando um dispositivo modificado
Esta seção descreve como determinar os tipos de falha do dispositivo, limpar os erros transitórios e substituir um dispositivo.
Determinando o tipo de falha do dispositivo
O termo dispositivo danificado é um tanto vago e pode descrever vários tipos de situações possíveis:
-
Bit rot: com o tempo, eventos aleatórios, como influências magnéticas e raios cósmicos, podem fazer com que os bits armazenados no disco se invertam. Estes eventos são relativamente raros, mas comuns o suficiente para provocar corrupção de dados em sistemas grandes ou que estão em funcionamento durante longos períodos de tempo.
-
Leituras ou gravações mal endereçadas – Erros de firmware ou falhas de hardware podem fazer com que leituras e gravações de blocos inteiros façam referência a locais incorretos no disco. Esses erros são normalmente transitórios, embora uma grande quantidade pode indicar um drive defeituosa.
-
Erro do administrador: os administradores podem substituir involuntariamente partes do disco por dados ruins (como copiar /dev/zero sobre partes do disco) que provocam a corrupção permanente deste. Estes erros são sempre transitórios.
-
Interrupções temporárias – Um disco pode não estar disponível durante um período de tempo, causando falhas de E/S. Esta situação está associada geralmente a dispositivos anexados à rede, embora os discos locais também possam sofrer interrupções temporárias. Estes erros podem ou não ser transitórios.
-
Hardware defeituoso ou anormal: essa situação é um resumo de todos os vários problemas que hardware defeituoso exibe, incluindo erros de E/S de consistência, transportes causando corrupção aleatória ou alguns números de falhas. Estes erros são normalmente permanentes.
-
Dispositivo off-line: se um dispositivo estiver off-line, supõe-se que o administrador o colocou nesse estado porque estava defeituoso. O administrador que colocou o dispositivo nesse estado pode determinar se esta suposição é precisa.
A determinação exata do problema pode ser um processo difícil. A primeira etapa é examinar as contagens de erros na saída zpool status. Por exemplo:
# zpool status -v tpool
pool: tpool
state: ONLINE
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: scrub completed after 0h0m with 2 errors on Tue Jul 13 11:08:37 2010
config:
NAME STATE READ WRITE CKSUM
tpool ONLINE 2 0 0
c1t1d0 ONLINE 2 0 0
c1t3d0 ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
/tpool/words
|
Os erros estão divididos em erros de E/S e erros de soma de verificação, e ambos podem indicar o possível tipo de falha. As operações normais prevêem uma pequena quantidade de erros (apenas alguns erros em longos períodos de tempo). Se você estiver vendo uma grande quantidade de erros, então essa situação provavelmente indica uma falha completa do dispositivo ou iminente. No entanto, um erro de administrador pode também resultar em uma grande contagem de erros. Outra fonte de informações é o log do sistema syslog. Se o registro mostrar um grande número de mensagens de driver de Fibre Channel ou de SCSI, então essa situação provavelmente indica sérios problemas de hardware. Se não for gerada nenhuma mensagem no syslog, então o dano é provavelmente transiente.
O objetivo é responder à seguinte pergunta:
É provável que ocorra outro erro neste dispositivo?
Os erros que acontecem somente uma vez são considerados transiente e não indicam falhas potenciais. Os erros que são persistentes ou suficientemente graves para indicar possível falha de hardware são considerados fatais. A ação de determinar o tipo de erro não está dentro do âmbito de nenhum software automatizado disponível atualmente com ZFS e muitas ações devem ser realizadas manualmente por você, o administrador. Depois de determinar o erro, a ação apropriada pode ser realizada. Apague os erros transitórios ou substitua o dispositivo devido aos erros fatais. Estes procedimentos de reparação estão descritos nas próximas seções.
Mesmo que os erros de dispositivo sejam considerados transientes, eles ainda podem ter provocado erros de dados incorrigíveis dentro do conjunto. Estes erros requerem procedimentos de reparação especiais, mesmo se o dispositivo estiver em boas condições ou tiver sido reparado. Para mais informações sobre a reparação de erros dos dados, consulte Reparando dados danificados.
Apagando erros transitórios
Se os erros de dispositivo são considerados transientes, nesse caso eles não são suscetíveis de afetar a integridade futura do dispositivo e podem ser seguramente eliminados para indicar que nenhum erro fatal ocorreu. Para apagar os contadores de erros dos dispositivos RAID-Z ou espelhados, use o comando zpool clear. Por exemplo:
# zpool clear tank c1t1d0 |
Essa sintaxe elimina os erros do dispositivo e elimina quaisquer contagens de erros associadas a este dispositivo.
Para eliminar todos os erros associados aos dispositivos virtuais em um conjunto e quaisquer contagens de erros de dados associadas ao conjunto, utilize sintaxe a seguir:
# zpool clear tank |
Para mais informações sobre como eliminar erros do conjunto, consulte Limpando erros de dispositivo de conjunto de armazenamento.
Substituindo um dispositivo em um pool de armazenamento do ZFS
Se o dano no dispositivo for permanente ou se houver grande possibilidade de que ocorram futuros danos permanentes, o dispositivo deve ser substituído. Depende da configuração se o dispositivo pode ou não ser substituído.
Determinando se um dispositivo pode ser substituído
Para que um dispositivo possa ser substituído, o pool deve estar no estado ONLINE. O dispositivo deve fazer parte de uma configuração redundante ou deve estar em boas condições (no estado ONLINE). Se o dispositivo faz parte de uma configuração redundante, devem existir réplicas suficientes para recuperar os dados bons. Se dois discos em um espelho de quatro lados estiverem defeituosos, então ambos discos podem ser substituídos porque há cópias em boas condições disponíveis. No entanto, se dois discos de um dispositivo virtual (raidz1) RAID-Z quadridirecional estiverem defeituosos, então nenhum dos discos pode ser substituído porque não há cópias suficientes para recuperar os dados. Se o dispositivo estiver danificado, mas estiver on-line, poderá ser substituído, contanto que o pool não se encontre no estado FAULTED. No entanto, os dados corrompidos do dispositivo são copiados no novo dispositivo, a menos que existam réplicas suficientes com dados bons.
Na configuração a seguir, o disco c1t1d0 pode ser substituído e os dados do conjunto são copiados da réplica integral c1t0d0:
mirror DEGRADED
c1t0d0 ONLINE
c1t1d0 FAULTED
|
O disco c1t0d0 também pode ser substituído, embora a autocorreção dos dados não seja possível devido à falta de réplicas boas disponíveis.
Na configuração a seguir, nenhum dos discos defeituosos pode ser substituído. Os discos ONLINE também não podem ser substituídos porque o próprio conjunto está defeituoso.
raidz FAULTED
c1t0d0 ONLINE
c2t0d0 FAULTED
c3t0d0 FAULTED
c4t0d0 ONLINE
|
Na configuração abaixo, ambos os discos de nível superior podem ser substituídos, embora os dados defeituosos presentes no disco sejam copiados no novo disco.
c1t0d0 ONLINE c1t1d0 ONLINE |
Se ambos os discos estiverem defeituosos, nenhuma substituição poderá ser efetuada porque o próprio conjunto pode estar defeituoso.
Dispositivos que não podem ser substituídos
Se a perda de um dispositivo tornar o conjunto defeituoso ou se o dispositivo contiver muitos erros de dados em uma configuração não redundante, então o dispositivo não poderá ser substituído com segurança. Sem redundâncias suficientes, não haverá dados bons com os quais reparar o dispositivo danificado. Neste caso, a única opção é destruir o conjunto e recriar a configuração e, em seguida, restaurar os dados de uma cópia de backup.
Para obter mais informações sobre a restauração de um pool inteiro, consulte Reparando o dano de todo o pool de armazenamento do ZFS.
Substituindo um dispositivo em um pool de armazenamento do ZFS
Depois de ter determinado qual dispositivo pode ser substituído, utilize o comando zpool replace para substitui-lo. Se você estiver substituindo o dispositivo danificado por um diferente, utilize uma sintaxe similar a seguinte:
# zpool replace tank c1t1d0 c2t0d0 |
Este comando migra os dados para o novo dispositivo a partir do dispositivo danificado ou de outros dispositivos do conjunto se este estiver em uma configuração redundante. Quando o comando estiver concluído, ele separa o dispositivo danificado da configuração, momento no qual o dispositivo pode ser removido do sistema. Se você já tiver removido o dispositivo e o tiver substituído por um dispositivo novo no mesmo local, use a forma simples de dispositivo do comando. Por exemplo:
# zpool replace tank c1t1d0 |
Este comando pega um disco não formatado, o formata adequadamente e, em seguida, começa a realizar o resilvering dos dados do restante da configuração.
Para obter mais informações sobre o comando zpool replace, consulte Substituindo dispositivos em um pool de armazenamento.
Exemplo 11–1 Substituindo um dispositivo em um pool de armazenamento do ZFS
O exemplo a seguir mostra como substituir um dispositivo (c1t3d0) no conjunto de armazenamento espelhado tank em um sistema Sun Fire x4500 do Oracle. Para substituir o disco c1t3d0 por um novo disco no mesmo local (c1t3d0), desconfigure o disco antes de substituí-lo. A etapa básica segue:
-
Coloque o disco off-line (c1t3d0) para ser substituido. Não é possível desconfigurar um disco que esteja sendo usado.
-
Utilize o comando cfgadm para identificar o disco (c1t3d0) para ser desconfigurado e desconfigure-o. O conjunto estará degradado com o disco off-line nessa configuração espelhada, mas continuará disponível.
-
Substitua fisicamente o disco (c1t3d0). Certifique-se de que o LED Ready to Remove azul esteja iluminado antes de remover fisicamente o drive defeituoso.
-
Reconfigure o disco (c1t3d0).
-
Coloque o novo disco (c1t3d0) novamente on-line.
-
Execute o comando zpool replace para substituir o disco (c1t3d0).
Observação –Se você definiu anteriormente o autoreplace da propriedade do conjunto para on, qualquer dispositivo novo, encontrado no mesmo local físico que um dispositivo que antes pertencia ao conjunto, será automaticamente formatado e substituído sem o uso do comando zpool replace. Este recurso pode não ser suportado em todos os hardwares.
-
Se um disco defeituoso for substituído automaticamente por um sobressalente, pode ser necessário desanexar o sobressalente depois que o disco defeituoso for substituído. Por exemplo, se c2t4d0 ainda é um sobressalente ativo depois que o disco falho é substituído, desanexe-o.
# zpool detach tank c2t4d0
O exemplo a seguir percorre através das etapas para substituir um disco em um conjunto de armazenamento do ZFS.
# zpool offline tank c1t3d0
# cfgadm | grep c1t3d0
sata1/3::dsk/c1t3d0 disk connected configured ok
# cfgadm -c unconfigure sata1/3
Unconfigure the device at: /devices/pci@0,0/pci1022,7458@2/pci11ab,11ab@1:3
This operation will suspend activity on the SATA device
Continue (yes/no)? yes
# cfgadm | grep sata1/3
sata1/3 disk connected unconfigured ok
<Physically replace the failed disk c1t3d0>
# cfgadm -c configure sata1/3
# cfgadm | grep sata1/3
sata1/3::dsk/c1t3d0 disk connected configured ok
# zpool online tank c1t3d0
# zpool replace tank c1t3d0
# zpool status tank
pool: tank
state: ONLINE
scrub: resilver completed after 0h0m with 0 errors on Tue Feb 2 13:17:32 2010
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c0t1d0 ONLINE 0 0 0
c1t1d0 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
c0t2d0 ONLINE 0 0 0
c1t2d0 ONLINE 0 0 0
mirror-2 ONLINE 0 0 0
c0t3d0 ONLINE 0 0 0
c1t3d0 ONLINE 0 0 0
errors: No known data errors
|
Observe que o zpool output anterior pode mostrar o disco novo e o antigo abaixo do cabeçalho replacing. Por exemplo:
replacing DEGRADED 0 0 0 c1t3d0s0/o FAULTED 0 0 0 c1t3d0 ONLINE 0 0 0 |
Esse texto significa que o processo de substituição está em andamento e que disco novo está sendo resilvered.
Se você for substituir um disco (c1t3d0) por outro (c4t3d0), então será necessário apenas executar o comando zpool replace. Por exemplo:
# zpool replace tank c1t3d0 c4t3d0
# zpool status
pool: tank
state: DEGRADED
scrub: resilver completed after 0h0m with 0 errors on Tue Feb 2 13:35:41 2010
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 ONLINE 0 0 0
c0t1d0 ONLINE 0 0 0
c1t1d0 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
c0t2d0 ONLINE 0 0 0
c1t2d0 ONLINE 0 0 0
mirror-2 DEGRADED 0 0 0
c0t3d0 ONLINE 0 0 0
replacing DEGRADED 0 0 0
c1t3d0 OFFLINE 0 0 0
c4t3d0 ONLINE 0 0 0
errors: No known data errors
|
Você pode precisar executar o comando zpool status várias vezes até que a substituição do disco seja concluída.
# zpool status tank
pool: tank
state: ONLINE
scrub: resilver completed after 0h0m with 0 errors on Tue Feb 2 13:35:41 2010
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c0t1d0 ONLINE 0 0 0
c1t1d0 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
c0t2d0 ONLINE 0 0 0
c1t2d0 ONLINE 0 0 0
mirror-2 ONLINE 0 0 0
c0t3d0 ONLINE 0 0 0
c4t3d0 ONLINE 0 0 0
|
Exemplo 11–2 Substituindo um dispositivo de registro com falhas
O exemplo a seguir mostra como recuperar de um dispositivo de log falho c0t5d0 no conjunto de armazenamento pool). A etapa básica segue:
-
Reveja a saída zpool status -x e a mensagem de diagnóstico FMA, aqui descrita:
-
Substitua fisicamente o dispositivo de registro com falha.
-
Coloque o dispositivo de log on-line.
-
Limpe a condição de erro do pool.
# zpool status -x
pool: pool
state: FAULTED
status: One or more of the intent logs could not be read.
Waiting for adminstrator intervention to fix the faulted pool.
action: Either restore the affected device(s) and run 'zpool online',
or ignore the intent log records by running 'zpool clear'.
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
pool FAULTED 0 0 0 bad intent log
mirror ONLINE 0 0 0
c0t1d0 ONLINE 0 0 0
c0t4d0 ONLINE 0 0 0
logs FAULTED 0 0 0 bad intent log
c0t5d0 UNAVAIL 0 0 0 cannot open
<Physically replace the failed log device>
# zpool online pool c0t5d0
# zpool clear pool
|
# zpool status -x
pool: pool
state: FAULTED
status: One or more of the intent logs could not be read.
Waiting for adminstrator intervention to fix the faulted pool.
action: Either restore the affected device(s) and run 'zpool online',
or ignore the intent log records by running 'zpool clear'.
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
pool FAULTED 0 0 0 bad intent log
mirror-0 ONLINE 0 0 0
c0t1d0 ONLINE 0 0 0
c0t4d0 ONLINE 0 0 0
logs FAULTED 0 0 0 bad intent log
c0t5d0 UNAVAIL 0 0 0 cannot open
<Physically replace the failed log device>
# zpool online pool c0t5d0
# zpool clear pool
|
Exibindo o status do resilvering
O processo de substituição de um dispositivo pode demorar um longo período de tempo, dependendo do tamanho do dispositivo e da quantidade de dados do conjunto. O processo de mover os dados de um dispositivo a outro é conhecido como resilvering e pode ser monitorado com a utilização do comando zpool status.
Os sistemas de arquivos tradicionais realizam resilvering de dados no nível do bloco. O ZFS, por eliminar a estrutura em camadas artificiais do gerenciador de volumes, pode realizar resilvering de uma forma muito mais eficaz e controlada. A duas principais vantagens deste recurso são:
-
O ZFS realiza resilvering somente da quantidade mínima de dados necessária. No caso de uma curta interrupção (como oposição a uma substituição completa do dispositivo), o disco inteiro pode ser resilvered em questão de minutos ou segundos. Quando todo o disco é substituído, o processo de resilvering leva o tempo proporcional à quantidade de dados usados no disco. Substituir um disco de 500 GB pode levar alguns segundos se o conjunto só possuir poucos gigabytes de espaço em disco utilizado.
-
O resilvering é um processo seguro e que pode ser interrompido. Se o sistema perder energia ou for reinicializado, o processo de resilvering recomeça exatamente de onde parou, sem necessidade de nenhuma intervenção manual.
Para exibir o processo de resilvering, use o comando zpool status. Por exemplo:
# zpool status tank
pool: tank
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, 22.60% done, 0h1m to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
replacing-0 DEGRADED 0 0 0
c1t0d0 UNAVAIL 0 0 0 cannot open
c2t0d0 ONLINE 0 0 0 85.0M resilvered
c1t1d0 ONLINE 0 0 0
errors: No known data errors
|
Neste exemplo, o disco c1t0d0 está sendo substituído pelo c2t0d0. Esse evento é observado na saída de status pela presença do dispositivo virtual substituição na configuração. Esse dispositivo não é real, não é possível criar um conjunto utilizando-o. O propósito desse dispositivo é exclusivamente exibir o progresso do resilvering e identificar qual dispositivo está sendo substituído.
Note que qualquer conjunto atualmente submetido ao resilvering é colocado em estado ONLINE ou DEGRADED porque o conjunto não pode fornecer o nível desejado de redundância até o processo de resilvering estar completo. Apesar de a E/S estar sempre programada com uma prioridade menor do que a E/S solicitada pelo usuário, o resilvering é realizado o mais rápido possível para minimizar o impacto no sistema. Depois que o resilvering estiver completo, a configuração reverte para a nova e completa configuração. Por exemplo:
# zpool status tank
pool: tank
state: ONLINE
scrub: resilver completed after 0h1m with 0 errors on Tue Feb 2 13:54:30 2010
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c2t0d0 ONLINE 0 0 0 377M resilvered
c1t1d0 ONLINE 0 0 0
errors: No known data errors
|
O conjunto está novamente ONLINE e o disco falho original (c1t0d0) foi removido da configuração.
Reparando dados danificados
As seções seguintes descrevem como identificar o tipo de corrupção de dados e como reparar os dados, se possível.
O ZFS utiliza a soma de verificação, redundância e autocorreção de dados para minimizar o risco de corrupção de dados. Por outro lado, a corrupção de dados pode ocorrer se um conjunto não é redundante, se a corrupção ocorreu enquanto um conjunto foi degradado ou uma série de eventos conspirados para corromper cópias múltiplas de uma parte dos dados. Em relação à origem, o resultado é o mesmo: Os dados estão corrompidos e, portanto, não podem ser acessados. A ação tomada depende do tipo de dados que estão corrompidos e de seu valor relativo. Podem ser corrompidos dois tipos básicos de dados:
-
Metadados do pool – O ZFS requer uma determinada quantidade de dados a ser processada para abrir um pool e acessar os conjuntos de dados. Se esses dados estão corrompidos, todo o conjunto ou parte do conjunto de dados se tornará indisponível.
-
Dados do objeto – Neste caso, a corrupção está dentro de um arquivo ou um diretório específico. Este problema pode fazer com que uma parte do arquivo ou diretório não possa ser acessada ou que o objeto fique totalmente danificado.
Os dados são verificados durante operações normais bem como através de um scrubbing. Para informações sobre como verificar a integridade do conjunto de dados, consulte Verificando a integridade do sistema de arquivos ZFS.
Identificando o tipo de corrupção de dados
Por padrão, o comando zpool status mostra somente que ocorreu uma corrupção, mas não mostra onde esta corrupção ocorreu. Por exemplo:
# zpool status monkey
pool: monkey
state: ONLINE
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: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010
config:
NAME STATE READ WRITE CKSUM
monkey ONLINE 8 0 0
c1t1d0 ONLINE 2 0 0
c2t5d0 ONLINE 6 0 0
errors: 8 data errors, use '-v' for a list
|
Cada erro indica somente que um erro ocorreu em um dado momento. Os erros não estão necessariamente presentes no sistema até este momento. Sob circunstâncias normais, esse é o caso. Certas interrupções podem resultar em corrupção de dados que são automaticamente reparados depois que a interrupção acaba. É realizado um scrubbing completo do pool a fim de examinar todos os blocos ativos no pool, assim o registro do erro é redefinido sempre que o scrubbing terminar. Se detectar que os erros já não estão presentes e não quiser esperar a conclusão do scrubbing, redefina todos os erros no pool com o comando zpool online.
Se a corrupção de dados estiver nos metadados de todo o pool, a saída é um pouco diferente. Por exemplo:
# zpool status -v morpheus
pool: morpheus
id: 1422736890544688191
state: FAULTED
status: The pool metadata is corrupted.
action: The pool cannot be imported due to damaged devices or data.
see: http://www.sun.com/msg/ZFS-8000-72
config:
morpheus FAULTED corrupted data
c1t10d0 ONLINE
|
No caso de corrupção de conjunto extenso, o conjunto é colocado em estado FAULTED porque o conjunto não pode fornecer o nível requerido de redundância.
Reparando arquivos ou diretórios corrompidos
Se um arquivo ou diretório está corrompido, o sistema ainda pode funcionar, dependendo do tipo de corrupção. Qualquer dano é efetivamente irrecuperável se não há nenhuma cópia boa de dados no sistema. Se os dados estão disponíveis, é preciso restaurar os dados afetados do backup. Mesmo assim, é possível recuperar essa corrupção sem ter que restaurar todo o pool.
Se o dano for dentro de um bloco de dados do arquivo, então o arquivo pode ser seguramente removido, eliminado o erro do sistema. Utilize o comando zpool status -v para exibir uma lista de nomes de arquivos com erros persistentes. Por exemplo:
# zpool status -v
pool: monkey
state: ONLINE
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: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010
config:
NAME STATE READ WRITE CKSUM
monkey ONLINE 8 0 0
c1t1d0 ONLINE 2 0 0
c2t5d0 ONLINE 6 0 0
errors: Permanent errors have been detected in the following files:
/monkey/a.txt
/monkey/bananas/b.txt
/monkey/sub/dir/d.txt
monkey/ghost/e.txt
/monkey/ghost/boo/f.txt
|
A lista de nomes de arquivos com erros persistentes devem ser descritos como os seguintes:
-
Se o caminho completo do arquivo for encontrado e o conjunto de dados estiver montado, o caminho completo do arquivo é exibido. Por exemplo:
/monkey/a.txt
-
Se o caminho completo do arquivo for encontrado, mas o conjunto de dados não estiver montado, então o nome do conjunto de dados é exibido sem a barra (/) precedente, seguido do caminho dentro do conjunto de dados do arquivo. Por exemplo:
monkey/ghost/e.txt
-
Se o número do objeto não puder ser traduzido com sucesso para o caminho do arquivo, devido a um erro ou a que o objeto não possui um caminho de arquivo verdadeiro associado a ele, como é o caso de dnode_t, então o nome do conjunto de dados seguido do número do objeto é exibido. Por exemplo:
monkey/dnode:<0x0>
-
Se um objeto no metaobject set (MOS) está corrompido, então uma marcação especial de <metadata>, seguida pelo número do objeto, é exibida.
Se a corrupção estiver dentro dos metadados de um arquivo ou diretório, a única opção é mover os arquivos para outro local. É possível mover seguramente qualquer arquivo ou diretório para um local menos conveniente, permitindo que o objeto original seja restaurado em seu lugar.
Reparando o dano de todo o pool de armazenamento do ZFS
Se o dano está nos metadados do conjunto e o dano previne o conjunto de ser aberto ou importado, então as opções a seguir estão disponíveis:
-
Tente recuperar o conjunto utilizando o comando zpool clear -F ou o comando zpoll import -F. Esses comandos tentam retornar as poucas últimas transações do conjunto para o estado operacional. É possível utilizar o comando zpool status para rever um conjunto danificado e as etapas de recuperação recomendadas. Por exemplo:
# zpool status pool: tpool state: FAULTED status: The pool metadata is corrupted and the pool cannot be opened. action: Recovery is possible, but will result in some data loss. Returning the pool to its state as of Wed Jul 14 11:44:10 2010 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool clear -F tpool'. A scrub of the pool is strongly recommended after recovery. see: http://www.sun.com/msg/ZFS-8000-72 scrub: none requested config: NAME STATE READ WRITE CKSUM tpool FAULTED 0 0 1 corrupted data c1t1d0 ONLINE 0 0 2 c1t3d0 ONLINE 0 0 4O processo de recuperação, como descrito acima, é utilizado pelo comando a seguir:
# zpool clear -F tpool
Se você tentar importar um conjunto de armazenamento danificado, irá visualizar mensagens similares as seguintes:
# zpool import tpool cannot import 'tpool': I/O error Recovery is possible, but will result in some data loss. Returning the pool to its state as of Wed Jul 14 11:44:10 2010 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool import -F tpool'. A scrub of the pool is strongly recommended after recovery.O processo de recuperação, como descrito acima, é utilizado pelo comando a seguir:
# zpool import -F tpool Pool tpool returned to its state as of Wed Jul 14 11:44:10 2010. Discarded approximately 5 seconds of transactions
Se o conjunto danificado está no arquivo zpool cache, o problema é descoberto quando o sistema é inicializado e o conjunto danificado é reportado no comando zpool status. Se o conjunto não estiver no arquivo zpool cache, ele não irá importar nem abrir com sucesso e você verá mensagens de conjuntos danificados quando tentar importar o conjunto.
-
Se o conjunto não pode ser recuperado pelo método de recuperação do conjunto descrito acima, restaure o conjunto e todos os seus dados pela cópia de backup. O mecanismo utilizado varia amplamente dependendo da configuração do conjunto e da estratégia de backup. Primeiro, salve a configuração como exibida pelo comando zpool status, assim é possível recriá-la depois que o conjunto for destruído. Então, utilize o comando zpool destroy -f para destruir o conjunto. Mantenha também, em um lugar seguro, um arquivo que descreva o layout dos conjuntos de dados e as diversas propriedades de conjunto, já que estas informações não poderão ser acessadas se o pool não puder ser acessado. Com a configuração do pool e o layout do conjunto de dados, você pode reconstruir a configuração completa depois de destruir o pool. Os dados podem, então, ser preenchidos usando o backup ou a estratégia de restauração de sua preferência.
Reparando um sistema não inicializável
O ZFS foi desenvolvido para ser robusto e estável apesar dos erros. Mesmo assim, erros de software ou certos problemas inesperados podem causar pane no sistema quando um conjunto é acessado. Como parte do processo de inicialização, cada pool deve ser aberto, o que significa que tais falhas farão com que o sistema entre em um ciclo de reinicialização por pane. Para recuperar a partir dessa situação, o ZFS deve ser informado para não procurar por qualquer conjunto ao iniciar.
O ZFS mantém um cache interno de pools disponíveis e suas configurações em /etc/zfs/zpool.cache. O local e o conteúdo deste arquivo são privados e estão sujeitos a alterações. Se o sistema torna-se não inicializável, inicialize as etapas none utilizando a opção de inicialização -m milestone=one . Depois que o sistema estiver inicializado, remonte o sistema de arquivos raiz como gravável e então renomeie ou mova o arquivo /etc/zfs/zpool.cache para outros locais. Essas ações fazem o ZFS esquecer que há quaisquer conjuntos existentes no sistema, prevenindo-o de tentar acessar o conjunto defeituoso causando o problema. Você pode, então, passar para o estado normal do sistema usando o comando svcadm milestone all. É possível usar um processo semelhante ao inicializar a partir de uma raiz alternativa para realizar reparações.
Depois que o sistema estiver inicializado, tente importar o conjunto utilizando o comando zpool import. Entretanto, esta ação provavelmente provocará o mesmo erro ocorrido durante a inicialização, pois o comando usa o mesmo mecanismo para acessar os pools. Se houver vários pools no sistema, adote o seguinte procedimento:
-
Renomeie ou mova o arquivo zpool.cache para outro local como discutido no texto anterior.
-
Determine qual conjunto possui problemas utilizando o comando fmdump -eV para exibir os conjuntos com erros fatais relatados.
-
Importe o conjunto um a um, ignorando os conjuntos que estão tendo problemas, como descrito na saída fmdump.
- © 2010, Oracle Corporation and/or its affiliates