Os sistemas de arquivos são construídos sobre dispositivos de armazenamento. Existem controladores RAID e controladores de disco, cada um executando seu próprio pequeno firmware. Existem caches para melhorar o desempenho. Existem discos com diferentes tamanhos de setor e existem discos que relatariam um tamanho de setor diferente dependendo de como você faz a pergunta.

Com tantas peças diferentes que constituem uma pilha de armazenamento típica, é um milagre que tudo funcione. No entanto, as coisas funcionam bem na maioria das vezes. Nas poucas vezes em que as coisas dão errado, precisamos de utilitários como o xfs_repair para nos tirar da bagunça.

As coisas podem dar errado quando você está escrevendo um arquivo e a energia cai ou há um kernel panic. Mesmo os dados latentes em um disco podem se deteriorar com o tempo, devido à mudança na estrutura física dos elementos de memória, isso é conhecido como bit pod. Em todos os casos, precisamos de um mecanismo para:

1. Verificar se os dados que estão sendo lidos são os mesmos que foram gravados pela última vez. Isso é implementado tendo uma soma de verificação para cada bloco de dados e comparando a soma de verificação para aquele bloco quando os dados estão sendo lidos. Se a soma de verificação corresponder, os dados não foram alterados
2. Uma maneira de reconstruir os dados corrompidos ou perdidos, seja de um bloco de espelho ou de um bloco de paridade.

Configuração de sandbox

Vamos configurar um testbench para executar uma rotina de reparo xfs em vez de usar discos reais com dados valiosos neles. Se você já tem um sistema de arquivos quebrado, você pode pular esta seção e ir direto para a próxima. Este testbench é composto de uma VM Ubuntu à qual um disco virtual está conectado, fornecendo armazenamento bruto. Você pode usar o VirtualBox para criar a VM e, em seguida, criar um disco adicional para anexar à VM.

Basta ir para as configurações de sua VM e em Configurações → Armazenamento seção, você pode adicionar um novo disco ao controlador SATA, você pode criar um novo disco. Conforme mostrado abaixo, mas certifique-se de que sua VM esteja desligada ao fazer isso.

Assim que o novo disco for criado, ligue a VM e abra o terminal. O comando lsblk lista todos os dispositivos de bloco disponíveis.

$ lsblk
disco sda 8: 0 0 60G 0
├─sda1 8: 1 0 1M 0 parte
└─sda2 8: 2 0 60G 0 parte /
sdb 8:16 0 100G 0 disco
sr0 11: 0 1 1024M 0 rom

Além do dispositivo de bloco principal sda, onde o sistema operacional está instalado, agora há um novo dispositivo sdb. Vamos criar rapidamente uma partição a partir dela e formatá-la com o sistema de arquivos XFS.

Abra o utilitário parted como usuário root:

$ parted -a / dev / sdb ideal

Vamos criar uma tabela de partição primeiro usando mklabel, seguido pela criação de uma única partição de todo o disco (que tem 107 GB de tamanho). Você pode verificar se a partição é feita listando-a usando o comando de impressão:

(dividido) mklabel gpt
(dividido) mkpart primário 0 107
(parted) print
(parted) sair

Ok, agora podemos ver usando lsblk que há um novo dispositivo de bloco sob o dispositivo sdb, chamado sdb1.

Vamos formatar este armazenamento como xfs e montá-lo no diretório / mnt. Novamente, execute as seguintes ações como root:

$ mkfs.xfs / dev / sdb1
$ mount / dev / sdb1 / mnt
$ df -h

O último comando irá imprimir todos os sistemas de arquivos montados e você pode verificar se / dev / sdb1 está montado em / mnt.

Em seguida, escrevemos vários arquivos como dados fictícios para desfragmentar aqui:

$ dd if = / dev / urandom de = / mnt / meuarquivo.contagem txt = 1024 bs = 1024

O comando acima iria escrever um arquivo myfile.txt de 1 MB de tamanho. Se quiser, você pode gerar automaticamente mais desses arquivos, espalhá-los por vários diretórios dentro do sistema de arquivos xfs (montado em / mnt) e, em seguida, verificar a fragmentação. Use bash ou python ou qualquer outra de sua linguagem de script favorita para isso.

Verificando e reparando erros

A corrupção de dados pode se infiltrar silenciosamente em seus discos sem o seu conhecimento. Se um bloco de dados não for lido e a soma de verificação não for comparada, o erro pode simplesmente aparecer na hora errada. Quando alguém está tentando acessar os dados, em tempo real. Em vez disso, é uma boa ideia executar uma varredura completa de todos os blocos de dados para a verificação de podridão de bits ou outros erros com frequência.

O utilitário xfs_scrub deve fazer essa tarefa para o seu. Inspirado em parte pelo comando scrub do OpenZFS, este recurso experimental está disponível apenas no xfsprogs versão 4.15.1-1ubuntu1 que não é uma versão estável. Se ele detectar o erro incorretamente, pode induzir você a causar corrupção de dados em vez de corrigi-lo! No entanto, se quiser experimentá-lo, você pode usá-lo em um sistema de arquivos montado usando o comando:

$ xfs_scrub / dev / sdb1

Antes de tentar reparar um sistema de arquivos corrompido, primeiro você terá que desmontá-lo. Isso evita que os aplicativos gravem inadvertidamente no sistema de arquivos quando deveriam ser deixados sozinhos.

$ umount / dev / sdb1

Reparar erros é tão simples quanto executar:

$ xfs_repair / dev / sdb1

Metadados essenciais são sempre mantidos como cópias múltiplas, mesmo se você não estiver usando RAID e se algo deu errado com o superbloco ou inodes, então este comando pode corrigir esse problema para você com toda a probabilidade.

Próximos passos

Se você está vendo dados corrompidos com frequência (ou mesmo uma vez, se estiver executando algo de missão crítica), considere substituir seus discos, pois isso pode ser um indicador precoce de um disco que está prestes a morrer.

Se um controlador falhar, ou uma placa RAID desistir de vida, nenhum software no mundo pode reparar o sistema de arquivos para você. Você não quer contas caras de recuperação de dados e nem quer longos períodos de inatividade, então fique de olho nesses SSDs e pratos giratórios!