Erros de disco silencioso e confiabilidade da troca do Linux

Meu entendimento é que discos rígidos e SSDs implementam alguma correção básica de erros dentro da unidade, e a maioria das configurações de RAID, por exemplo, mdadm, depende disso para decidir quando uma unidade falhou em corrigir um erro e precisa ser colocada offline. No entanto, isso depende do armazenamento ser 100% preciso no diagnóstico de erros. Não é assim, e uma configuração comum como um espelho RAID-1 de duas unidades ficará vulnerável: suponha que alguns bits em uma unidade estejam silenciosamente corrompidos e a unidade não relate um erro de leitura. Assim, sistemas de arquivos como btrfs e ZFS implementam suas próprias somas de verificação, para não confiar em firmwares de unidade de buggy, cabos SATA com falha e assim por diante.

Da mesma forma, a RAM também pode ter problemas de confiabilidade e, portanto, temos RAM de ECC para resolver esse problema.

Minha pergunta é a seguinte : qual é a maneira canônica de proteger o arquivo de troca do Linux contra corrupção silenciosa / rot de bit não detectada pelo firmware da unidade em uma configuração de dois discos (ou seja, usando drivers do kernel da linha principal)? Parece-me que uma configuração que não possui proteção de ponta a ponta aqui (como a fornecida pelo btrfs) nega um pouco a tranqüilidade trazida pela RAM do ECC. No entanto, não consigo pensar em um bom caminho:

• O btrfs não suporta arquivos de troca. Você pode configurar um dispositivo de loop a partir de um arquivo btrfs e fazer uma troca por ele. Mas isso tem problemas:
  • Gravações aleatórias não funcionam bem: https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
  • A sugestão para desativar a cópia na gravação também desabilitará a soma de verificação - derrotando assim todo o objetivo deste exercício. Eles assumem que o arquivo de dados tem suas próprias proteções internas.
• O ZFS no Linux permite usar um ZVOL como swap, o que eu acho que poderia funcionar: http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap - no entanto, pela minha leitura, o ZFS normalmente exige muita memória e faz com que funcione em uma troca Somente a aplicação soa como algum trabalho para descobrir isso. Eu acho que essa não é minha primeira escolha. Por que você precisaria usar algum módulo de kernel out-of-tree para ter uma troca confiável está além de mim - certamente há uma maneira de fazer isso com a maioria das distribuições / kernels Linux modernos nos dias de hoje?
• Na verdade, havia um encadeamento em uma lista de discussão do kernel do Linux com patches para ativar somas de verificação no próprio gerenciador de memória, exatamente pelas razões que discuto nesta pergunta: http://thread.gmane.org/gmane.linux.kernel/989246 - infelizmente, até onde eu sei, o patch morreu e nunca chegou a montante por razões desconhecidas para mim. Que pena, parecia um bom recurso. Por outro lado, se você colocar swap em um RAID-1 - se a corrupção estiver além da capacidade de reparo da soma de verificação, você desejará que o gerenciador de memória tente ler da outra unidade antes de entrar em pânico ou o que quer que seja. provavelmente fora do escopo do que um gerente de memória deve fazer.

Em suma:

• RAM possui ECC para corrigir erros
• Os arquivos no armazenamento permanente possuem btrfs para corrigir erros
• Swap has ??? <--- esta é a minha pergunta

Confiamos na integridade dos dados recuperados da troca porque o hardware de armazenamento possui somas de verificação, CRCs e outros.

Em um dos comentários acima, você diz:

verdade, mas não protege contra inversões de bits fora do próprio disco

"It" significa as somas de verificação do disco aqui.

Isso é verdade, mas o SATA usa CRCs de 32 bits para comandos e dados. Portanto, você tem uma chance de 1 em 4 bilhões de dados corrompidos indetectável entre o disco e o controlador SATA. Isso significa que uma fonte de erro contínua pode introduzir um erro tão freqüentemente quanto cada 125 MiB transferido, mas uma fonte de erro rara e aleatória, como raios cósmicos, causaria erros indetectáveis ​​a uma taxa extremamente pequena.

Perceba também que, se você tiver uma fonte que causa um erro não detectado a uma taxa próxima a um por 125 MiB transferidos, o desempenho será terrível, devido ao alto número de erros detectados que requerem transferência. O monitoramento e o log provavelmente alertarão você sobre o problema a tempo de evitar corrupção não detectada.

Quanto às somas de verificação da mídia de armazenamento, todo disco SATA (e antes dela, PATA) usa somas de verificação por setor de algum tipo. Um dos recursos característicos dos discos rígidos "corporativos" são setores maiores protegidos por recursos adicionais de integridade de dados , reduzindo bastante a chance de erro não detectado.

Sem essas medidas, não haveria sentido em todo o setor de reposição em todos os discos rígidos: o próprio disco não podia detectar um setor defeituoso, portanto nunca poderia trocar novos setores.

Em outro comentário, você pergunta:

se o SATA é tão confiável, por que existem sistemas de arquivos com soma de verificação como ZFS, btrfs, ReFS?

De um modo geral, não estamos pedindo swap para armazenar dados a longo prazo. O limite no armazenamento de swap é o tempo de atividade do sistema , e a maioria dos dados no swap não dura tanto tempo, pois a maioria dos dados que passam pelo sistema de memória virtual do sistema pertence a processos de vida muito mais curta.

Além disso, os tempos de atividade geralmente diminuíram ao longo dos anos, com o aumento da frequência de kernel e libcatualizações, virtualização, arquiteturas em nuvem etc.

Além disso, a maioria dos dados no swap é inerentemente desutilizada em um sistema bem gerenciado, sendo um que não fica sem a RAM principal. Nesse sistema, as únicas coisas que acabam em troca são as páginas que o programa não usa com frequência, se é que alguma vez. Isso é mais comum do que você imagina. A maioria das bibliotecas dinâmicas vinculadas pelos seus programas possui rotinas que o programa não usa, mas elas precisam ser carregadas na RAM pelo vinculador dinâmico . Quando o sistema operacional vê que você não está usando todo o texto do programa na biblioteca, ele o troca, abrindo espaço para código e dados que seus programas estão usando. Se essas páginas de memória trocadas estiverem corrompidas, quem saberia?

Compare isso com o ZFS, onde esperamos que os dados sejam armazenados de maneira durável e persistente, para que durem não apenas além do tempo de atividade atual do sistema, mas também além da vida útil dos dispositivos de armazenamento individuais que compõem o sistema de armazenamento. O ZFS e outros estão resolvendo um problema com uma escala de tempo aproximadamente duas ordens de grandeza maior que o problema resolvido pelo swap. Portanto, temos requisitos de detecção de corrupção muito mais altos para o ZFS do que para a troca do Linux.

O ZFS e outros diferem do swap de outra maneira importante aqui: não trocamos os sistemas de arquivos por RAID juntos. Quando vários dispositivos de troca estão em uso em uma única máquina, é um esquema JBOD , não como o RAID-0 ou superior. (por exemplo , esquema de arquivos de troca encadeados do macOS , Linux swaponetc.) Como os dispositivos de troca são independentes, e não interdependentes, como no RAID, não precisamos de uma soma de verificação abrangente, pois a substituição de um dispositivo de troca não envolve a procura de outros dispositivos de troca interdependentes. os dados que devem ir no dispositivo de substituição. Em termos do ZFS, não trocamos os dispositivos novamente por cópias redundantes em outros dispositivos de armazenamento.

Tudo isso significa que você deve usar um dispositivo de troca confiável. Uma vez, usei um gabinete USB HDD externo de US $ 20 para resgatar um pool ZFS enfermo, apenas para descobrir que o próprio gabinete não era confiável, introduzindo erros próprios no processo. A forte soma de verificação do ZFS me salvou aqui. Você não pode se safar com um tratamento tão descuidado da mídia de armazenamento com um arquivo de troca. Se o dispositivo de troca está morrendo e, portanto, está se aproximando do pior caso em que poderia injetar um erro indetectável a cada 125 MiB transferidos, você simplesmente precisa substituí-lo, o mais rápido possível.

O sentido geral de paranóia nesta questão se resume a um exemplo do problema dos generais bizantinos . Leia sobre isso, pondere a data de 1982 no artigo acadêmico que descreve o problema para o mundo da ciência da computação e, em seguida, decida se você, em 2019, tem novas idéias para adicionar a esse problema. Se não, talvez você use a tecnologia projetada por três décadas de graduados em CS, que todos conhecem o problema dos generais bizantinos.

Este é um terreno bem pisado. Você provavelmente não pode ter uma idéia, objeção ou solução que ainda não tenha sido discutida até a morte nas revistas de ciência da computação.

O SATA certamente não é totalmente confiável, mas, a menos que você ingresse no meio acadêmico ou em uma das equipes de desenvolvimento do kernel, não estará em condições de adicionar materialmente ao estado da arte aqui. Esses problemas já estão bem presentes, como você já observou: ZFS, btrfs, ReFS ... Como usuário do sistema operacional, basta confiar que os criadores do sistema operacional estão cuidando desses problemas, porque eles também sabem sobre os generais bizantinos.

É atualmente não é prático para colocar o seu arquivo de troca em cima do ZFS ou Btrfs, mas se o acima não tranquilizá-lo, você poderia pelo menos colocá-lo no topo xfs ou ext4. Isso seria melhor do que usar uma partição de troca dedicada.

integridade dm

Consulte: Documentação / mapeador de dispositivos / dm-integridade.txt

dm-integritynormalmente seria usado no modo de diário. No caso de troca, você pode fazer isso sem o diário. Isso pode reduzir significativamente a sobrecarga de desempenho. Não tenho certeza se você precisaria reformatar a partição de troca por integridade em cada inicialização, para evitar a detecção de erros após um desligamento imundo.

No anúncio inicial dedm-integrity , o autor declara uma preferência por "proteção de integridade de dados no nível superior". No caso de troca, isso abriria a possibilidade de armazenar as somas de verificação na RAM. No entanto, essa opção exigiria modificações não triviais no código de troca atual e aumentaria o uso de memória. (O código atual rastreia a troca com eficiência usando extensões, não páginas / setores individuais).

DIF / DIX?

O suporte a DIX foi adicionado pela Oracle no Linux 2.6.27 (2008).

O uso do DIX fornece integridade de ponta a ponta?

Você pode consultar seu fornecedor. Eu não sei como você poderia dizer se eles estão mentindo sobre isso.

O DIX é necessário para proteger os dados em voo entre o SO (sistema operacional) e o HBA .

O DIF por si só aumenta a proteção dos dados em voo entre o HBA e o dispositivo de armazenamento . (Veja também: apresentação com alguns números sobre a diferença nas taxas de erro ).

Precisamente porque a soma de verificação no campo de proteção é padronizada, é tecnicamente possível implementar comandos DIX sem fornecer nenhuma proteção para os dados em repouso. Basta fazer com que o HBA (ou dispositivo de armazenamento) gere novamente a soma de verificação no momento da leitura. Essa perspectiva foi esclarecida pelo projeto original DIX.

• DIF / DIX são somas de verificação ortogonais a lógicas de bloco
  • Nós ainda te amamos, btrfs!
  • Erros de soma de verificação de bloco lógico são usados ​​para detecção de dados corrompidos
  • A detecção acontece no momento da LEITURA
  • ... que pode ser meses depois, o buffer original é perdido
  • Quaisquer cópias redundantes também podem ser ruins se o buffer original estiver ilegível
• DIF / DIX são sobre prevenção proativa de corrupção
  • Impedindo que dados ruins sejam armazenados em disco em primeiro lugar
  • ... e descobrir problemas antes que o buffer original seja apagado da memória

- lpc08-data-integridade.pdf de oss.oracle.com

Uma das primeiras publicações sobre DIX menciona a possibilidade de usar DIX entre OS e HBA, mesmo quando a unidade não suporta DIF.

A mentira completa é relativamente improvável em contextos "empresariais" em que o DIX é usado atualmente; as pessoas notariam isso. Além disso, o DIF foi baseado no hardware existente, que podia ser formatado com setores de 520 bytes. O protocolo para usar o DIF supostamente requer que você primeiro reformate a unidade, consulte, por exemplo, o sg_formatcomando.

O mais provável é uma implementação que não segue o verdadeiro princípio de ponta a ponta . Para dar um exemplo, é mencionado um fornecedor que suporta uma opção de soma de verificação mais fraca para o DIX salvar os ciclos da CPU, que é então substituída por uma soma de verificação mais forte na pilha. Isso é útil, mas não é uma proteção completa de ponta a ponta.

Como alternativa, um sistema operacional pode gerar suas próprias somas de verificação e armazená-las no espaço de tags do aplicativo. No entanto, não há suporte para isso no Linux atual (v4.20) . O comentário, escrito em 2014, sugere que isso pode ocorrer porque "pouquíssimos dispositivos de armazenamento permitem o uso do espaço de tags do aplicativo". (Não tenho certeza se isso se refere ao próprio dispositivo de armazenamento, ao HBA ou a ambos).

Que tipo de dispositivos DIX estão disponíveis que funcionam com Linux?

A separação dos buffers de metadados de dados e integridade, bem como a escolha nas somas de verificação, é chamada de DIX (Data Integrity Extensions). Como essas extensões estão fora do escopo dos órgãos de protocolo (T10, T13), a Oracle e seus parceiros estão tentando padronizá-las na Storage Networking Industry Association.

- v4.20 / Documentation / block / data-identity.txt

A Wikipedia me diz que o DIF é padronizado no NVMe 1.2.1. Para HBAs SCSI, parece um pouco difícil definir isso se não tivermos um padrão para o qual apontar. No momento, pode ser mais preciso falar sobre o suporte ao "Linux DIX" :-). Existem dispositivos disponíveis:

O SCSI T10 DIF / DIX [sic] é totalmente suportado no Red Hat Enterprise Linux 7.4, desde que o fornecedor do hardware o qualifique e forneça suporte completo para a configuração específica do HBA e da matriz de armazenamento. O DIF / DIX não é suportado em outras configurações, não é suportado no dispositivo de inicialização e não é suportado em convidados virtualizados.

Atualmente, os seguintes fornecedores são conhecidos por fornecer esse suporte ...

- Notas da versão RHEL 7.5, Capítulo 16. Armazenamento

Todo o hardware mencionado nas notas de versão do RHEL 7.5 é Fibre Channel.

Eu não conheço esse mercado. Parece que o DIX pode se tornar mais amplamente disponível em servidores no futuro. Não sei por que motivo ele estaria disponível para discos SATA de consumo - até onde sei, não existe um padrão de fato para o formato de comando. Ficarei interessado em ver se ele fica disponível mais amplamente no NVMe.

Swap has ??? <--- esta é a minha pergunta

A troca ainda não está protegida no Linux (mas consulte UPD).

Bem, é claro que o ZFS no Linux é capaz de ser um armazenamento de troca, mas ainda há um bloqueio em algumas circunstâncias - revogando efetivamente essa opção.

Btrfs ainda não pode lidar com arquivos de troca . Eles mencionam o possível uso do loopback, embora o desempenho seja ruim. Há uma indicação pouco clara de que o Linux 5 possa finalmente ter (?)…

Patches para proteger a troca convencional em si com somas de verificação não chegaram ao mainstream.

Então, tudo em tudo: não. O Linux ainda tem uma lacuna lá.

UPD. : Como o @ sourcejedi aponta, existe uma ferramenta como dm-integridade. O kernel do Linux desde a versão 4.12 obteve o alvo do mapeador de dispositivos que pode ser usado para fornecer somas de verificação a qualquer dispositivo de bloco geral e aqueles que são para troca não são exceção. As ferramentas não são amplamente incorporadas nas principais distros e a maioria delas não tem suporte no subsistema udev, mas eventualmente isso deve mudar. Quando emparelhado com um provedor de redundância, digamos colocado no topo do MD, também conhecido como Linux Software RAID, deve ser possível não apenas detectar a podridão de bits, mas também redirecionar a solicitação de E / S para dados íntegros, porque a integridade dm indicaria questão e MD deve lidar com isso.

Eu não acho que exista um caminho "canônico", então a seguir é minha opinião pessoal.

Depois de monitorar o avanço do btrfs do ponto de vista de um usuário em potencial, devo dizer que ele ainda é de alguma maneira obscuro. Existem recursos maduros e prontos para uso em produção e há recursos aparentemente imaturos e perigosos para o uso.

Pessoalmente, não tenho tempo para decidir qual recurso usar e quais não, deixando de lado o tempo necessário para descobrir como desativar ou ativar esses recursos.

Por outro lado, o ZFS é sólido e maduro (IMHO). Portanto, para responder sua pergunta, eu usaria o ZFS (a propósito, ele não consome muita memória - veja abaixo).

Mas para você, o btrfs pode ser a escolha certa, já que você o está usando (se eu entendi direito), e um dos comentários acima mostra como usá-lo para troca.

Por puro acaso, eu coloquei alguns servidores Linux no ZFS nos últimos dias, sempre incluindo o sistema de arquivos raiz e a troca. Antes de fazer isso, fiz uma pesquisa minuciosa, o que me levou vários dias. Um breve resumo do que aprendi:

Consumo de memória do ZFS

Há um mal-entendido comum sobre o consumo de memória do ZFS. O ZFS geralmente não consome muita memória; de fato, ele roda com TBs de armazenamento em máquinas com 2 GB de RAM. Somente se você usar a desduplicação (desativada por padrão), ela precisará de muita e muita RAM.

Detecção / correção de erros de hardware

Se os mecanismos SATA, PATA, RAID ou outros mecanismos de detecção / correção de erros são suficientes para a integridade dos dados, é um assunto que causa discussões intermináveis ​​e até guerras de chamas em todos os lugares da rede. Teoricamente, um dispositivo de armazenamento de hardware deve relatar (e possivelmente corrigir) qualquer erro encontrado, e o hardware de transmissão de dados em todos os níveis (chipset, memória etc.) também.

Bem, eles não o fazem em todos os casos ou reagem surpreendentemente a erros. Como exemplo, vamos dar uma configuração típica de RAID5. Normalmente, se um disco tiver um problema, ele o reportará ao RAID, que por sua vez constrói os dados a serem lidos dos outros discos e os transmite, mas também os grava de volta no disco defeituoso (que, por sua vez, provavelmente remapeia o setor antes de escrever os dados); se o mesmo disco relatar muitos erros, o RAID o coloca offline e informa o administrador (se configurado corretamente).

Até agora, tudo bem, mas há casos em que dados defeituosos saem de um disco sem que o disco relate um erro (consulte a próxima seção). A maioria dos RAIDs pode detectar essa situação usando as informações de paridade, mas sua reação é estúpida: em vez de relatar o erro e impedir a transmissão dos dados, eles apenas recalcularão a paridade com base nos dados defeituosos e gravarão a nova paridade na respectiva , marcando assim os dados defeituosos como corretos para sempre.

Esse comportamento é razoável? Até onde eu sei, a maioria dos controladores RAID5 de hardware e até o RAID md do Linux funcionam dessa maneira.

Não sei sobre a correção de erros do btrfs, mas você deve ler os documentos com cuidado mais uma vez, principalmente se estiver usando o RAID do btrfs.

Podridão silenciosa

Apesar de todas as guerras de chamas e discussões (pseudo-) científicas: a realidade é diferente da teoria e a podridão silenciosa dos bits definitivamente acontece, embora a teoria possa indicar o contrário (podridão silenciosa dos bot geralmente significa que os dados no armazenamento de hardware são corrompidos sem que o dispositivo de armazenamento relate erro quando esses dados forem lidos, mas adicionarei bits invertidos em qualquer lugar do caminho de transmissão a esta definição).

O fato de isso acontecer não é minha opinião pessoal: pelo menos, Google, Amazon e CERN publicaram white papers detalhados sobre exatamente esse assunto. Os documentos estão disponíveis ao público para download gratuito. Eles fizeram experimentos sistemáticos com vários milhões de discos rígidos e centenas de milhares de servidores / dispositivos de armazenamento, porque tiveram problemas com corrupção de dados não detectada ou porque queriam saber o que fazer para evitá-lo antes que acontecesse.

Em resumo, os dados em seus farms de servidores foram corrompidos com uma taxa significativamente maior do que as estatísticas do MTBF ou outra teoria permitia esperar. Por significativamente mais alto, quero dizer ordens de magnitude.

Portanto, a podridão silenciosa dos bits, ou seja, corrupção de dados não detectada em qualquer ponto do caminho de transmissão, é um problema da vida real.

Duração dos dados

Warren Young está correto quando diz que os dados de troca têm uma vida útil curta. Mas eu gostaria de acrescentar a seguinte consideração: Não apenas os dados (no sentido dos documentos) entram em troca, mas (talvez ainda mais provavelmente) partes do sistema operacional ou outro software em execução . Se eu tiver um MP3 em troca, eu poderia viver um pouco. Se (devido a uma situação extrema) partes do meu software de servidor httpd de produção estiverem em troca, de maneira alguma posso viver com um bit invertido que mais tarde leva à execução de código corrompido, se não for detectado.

Epílogo

Para mim, o ZFS resolve esses problemas ou, mais precisamente, os afasta dos discos para a memória e, assim, reduz a probabilidade de rotação silenciosa de bits em algumas ordens de magnitude. Além disso, se configurado corretamente (ou seja, espelha em vez de RAID), ele fornece uma correção de erro limpa e razoável, que funciona como o esperado e pode ser facilmente entendida depois de tudo.

Dito isto, observe que você nunca terá segurança absoluta. Pessoalmente, confio mais na minha RAM do ECC do que nos meus discos e estou convencido de que o ZFS com suas somas de verificação de ponta a ponta reduz a probabilidade de problemas em ordens de magnitude. Eu nunca recomendaria o uso do ZFS sem RAM de ECC.

Isenção de responsabilidade: não estou de forma alguma associado a nenhum fornecedor ou desenvolvedor do ZFS. Isso vale para todas as variantes (bifurcações) do ZFS. Eu me tornei fã dele nos últimos dias ...