O que acontece com as gravações perdidas após um zpool clear?

Question

Estou tentando entender o comportamento do ZFS sob uma condição específica, mas a documentação não é muito explícita sobre isso, portanto, estou adivinhando.

Suponha que tenhamos um zpool com redundância. Tome a seguinte sequência de eventos:

1. Um problema surge na conexão entre o dispositivo D e o servidor. Isso causa um grande número de falhas e, portanto, o ZFS faz uma falha no dispositivo, colocando o pool em estado degradado.

2. Enquanto o pool está em estado degradado, o pool sofre mutação (os dados são gravados e / ou alterados).

3. O problema de conectividade é reparado fisicamente de tal forma que o dispositivo D é confiável novamente .

4. Sabendo que a maioria dos dados em D é válida, e não querendo enfatizar desnecessariamente o pool com um resilver, o administrador executa zpool clear pool D . Isso é indicado pela documentação do Oracle como a ação apropriada em que a falha ocorreu devido a um problema transitório que foi corrigido.

Li que zpool clear apenas limpa o contador de erros e restaura o dispositivo para o status on-line. No entanto, isso é um pouco problemático, porque se isso for tudo , ele deixará o pool em um estado inconsistente!

Isso ocorre porque as mutações na etapa 2 não serão gravadas com êxito em D. Em vez disso, D refletirá o estado do pool antes da falha de conectividade. Obviamente, esse não é o estado normativo de um zpool e pode levar à perda de dados em caso de falha de outro dispositivo - no entanto, o status do pool não refletirá esse problema!

Eu diria pelo menos que, com base nos robustos mecanismos de integridade do ZFS, uma tentativa de ler os dados mutados de D pegaria os erros e os repararia. No entanto, isso levanta dois problemas:

1. Não é garantido que as leituras afetem todas as mutações, a menos que uma depuração seja feita; e

2. Uma vez que o ZFS faz acertar os dados mutados, (eu acho) pode criticar a unidade novamente porque parece que o ZFS está corrompendo os dados, já que não lembra as falhas de gravação anteriores.

Teoricamente, o ZFS poderia contornar esse problema mantendo o controle de mutações que ocorrem durante um estado degradado e gravando-as de volta em D quando estiver desmarcada. Por alguma razão, suspeito que não é o que acontece, no entanto.

Espero que alguém com conhecimento profundo do ZFS possa lançar alguma luz sobre esse aspecto.

    

Answer 1

"Teoricamente, o ZFS poderia contornar esse problema mantendo o controle de mutações que ocorrem durante um estado degradado e gravando-as novamente em D quando estiver limpo. Por alguma razão, suspeito que não é o que acontece, no entanto."

Na verdade, isso é quase exatamente o que pode ser feito nessa situação. Veja, toda vez que o disco em um pool do ZFS é gravado, o id da transação do pool global atual é gravado no disco. Por exemplo, digamos que você tenha o cenário explicado e o tempo total entre a perda de conexão e a recuperação seja menor que 127 * txg_timeout (e isso está fazendo muitas suposições brutas sobre a carga no pool e algumas outras coisas , mas diga metade disso por segurança típica, então se txg_timeout é de 10 segundos, então 600 segundos ou 10 minutos é um tempo razoável para esperar que isso continue funcionando).

No momento antes da desconexão, o pool conseguiu gravar com êxito gravações relacionadas ao ID de transação 20192. O tempo passa e o disco volta. No momento em que o disco está novamente disponível, o pool já passou por vários grupos de transações e está no ID de transação 20209. Nesse ponto, ainda há todas as possibilidades de o ZFS poder fazer o que é chamado de 'resilver rápido', onde ele resilversa o disco, mas SOMENTE para o ID de transação de 20193 até 20209, em oposição a um resilver completo da unidade. Isso rapidamente e eficientemente recupera o disco em especificação com o restante do pool.

No entanto, o método para iniciar essa atividade não é 'zpool clear'. Se tudo funcionasse como deveria, o resilver deveria ter sido chutado automaticamente no momento em que o disco voltasse a ficar saudável. Na verdade, pode ter sido tão rápido que você nunca viu. Nesse caso, 'zpool clear' seria a atividade adequada para limpar a contagem de erros ainda visíveis que teria aparecido quando o dispositivo desapareceu em primeiro lugar. Dependendo da versão do zfs que você está usando, em que sistema operacional ele está, de que maneira o dispositivo está sendo listado pelo zfs no momento e há quanto tempo ele está nesse estado, a maneira "correta" de corrigir isso varia. Na verdade, pode ser 'zpool clear' (limpando os erros, e o próximo acesso da unidade deve notar a falta de sincronização txg id e kick no resilver) ou você pode precisar usar 'zpool online' ou 'zpool replace' .

O que estou acostumado a ver, quando tudo isso funciona corretamente, o disco está desaparecendo e a unidade entra em um estado de OFFLINE ou DEGRADED ou FAULTED ou UNAVAIL ou REMOVED. Então, quando a unidade se torna acessível novamente em um nível do sistema operacional, FMA e outros mecanismos do sistema operacional entram em ação e o ZFS percebe que o disco retornou, e há um resilver rápido e o dispositivo aparece no status zpool como ONLINE novamente, mas ainda pode ter um contagem de erros associada a ele. A chave é que está no status ONLINE, o que indica o sucesso do reparo automático (resilver). Você pode testá-lo em qualquer unidade, puxando-o para fora, aguardando alguns segundos e verificando 'zpool status' e, em seguida, conectando o disco novamente e verificando 'zpool status' novamente e vendo o que acontece. O ZFS não é a única peça móvel aqui - o ZFS na verdade depende em grande parte de outras mecânicas do sistema operacional para informá-lo do status do disco, e se essas mecânicas falharem você terá sintomas diferentes do que se eles obtiverem sucesso.

Em qualquer evento, o resilver rápido pode ser executado e bem-sucedido, ou não é possível ou falha. Se o último, o disco terá para completar um resilver completo antes de retornar ao serviço, então seus dois problemas listados na parte inferior do seu post normalmente não devem ser possíveis, a menos que a substituição administrativa tenha permitido um disco com um txgid incompatível para reentrar em um pool sem qualquer forma de correção para essa disparidade (geralmente não deve ser possível). Se isso acontecesse, eu suspeitaria que o próximo acesso ao drive resultaria em um resilver rápido (e ter sucesso, ou falhar e derrubar o disco para um resilver completo) ou acabaria chutando o disco para fora - - ou possivelmente entrar em pânico, devido à disparidade txgid. Em qualquer um desses eventos, o que não aconteceria seria a perda de dados ou o retorno de dados incorretos para uma solicitação.

    

Answer 2

Observe que:

1. Cada pedaço de dados tem soma de verificação justa no ZFS. Portanto, o ZFS sabe qual unidade contém os dados corretos na configuração redundante quando houver falha. A execução de zpool scrub ZFSPOOL consertará dados ou distribuirá dados para todas as unidades em execução para o RADZ.
2. O ZFS emprega correção de erros do Reed-Solomon , que é melhor para explosões de erros. A unidade ausente é uma explosão de erros, que o R-S pode corrigir.

Recebi muitos erros de DMA nas unidades, quando o problema de ar condicionado no datacenter e o ZFS conseguiram corrigir essa confusão. E foi apenas um simples espelho.

Eu me lembro do vídeo promocional emitido pelo SUN quando eles introduziram o ZFS ... eles criaram o RAIDZ em unidades flash USB implantadas em hub USB de 8 portas e alteraram aleatoriamente a posição no hub para alguns deles enquanto executavam I / O no pool observando não falta de energia.