Quando o SLES Btrfs entra em modo somente leitura: faça um diagnóstico antes de remontar.

Se um sistema de arquivos Btrfs do SUSE Linux Enterprise reportar "Sistema de arquivos somente leitura", primeiro verifique se ele foi montado intencionalmente em modo somente leitura ou se passou para esse modo após um erro. Verifique as opções de montagem, o espaço livre e o log do kernel antes de tentar remontá-lo. Use o Snapper para reverter e obter um snapshot inicializável do sistema; se o Btrfs registrou erros de E/S ou de metadados, proteja os dados e diagnostique o caminho de armazenamento antes de gravar novamente no sistema de arquivos.

1. Diferencie uma montagem intencional somente leitura de um erro do sistema de arquivos.

Substitua /datapelo ponto de montagem afetado ou, /para raiz, pelo nome do ponto de montagem.

findmnt -T /data -o SOURCE,FSTYPE,OPTIONS
sudo btrfs filesystem show /data

No primeiro comando, procure por ` --read-only` roou rw`--read-only` nas opções. Um snapshot do Snapper em modo somente leitura deve rejeitar gravações. Uma montagem configurada com `--read- roonly` /etc/fstabtambém pode ser intencional. O Btrfs também pode alternar para o modo somente leitura após erros graves de transação, metadados ou dispositivo. Nesse caso, executar `--read-only` repetidamente mount -o remount,rwnão corrige a causa e pode falhar imediatamente.

Se o sistema de arquivos foi montado deliberadamente em modo somente leitura, o dispositivo está íntegro e o log do kernel não apresenta erros de Btrfs ou de E/S, uma montagem de dados normal pode ser remontada em modo leitura/gravação:

sudo mount -o remount,rw /data
findmnt -T /data -o TARGET,OPTIONS

Não utilize esse comando para recuperação de um snapshot somente leitura inicializado ou de um sistema de arquivos somente leitura forçado por erro. Uma remontagem bem-sucedida confirma a capacidade de gravação, não a integridade do sistema de arquivos.

2. Verifique se a pressão no espaço é o problema real.

O Btrfs pode ficar sem espaço alocável mesmo quando uma visualização básica do disco parece surpreendente, porque a alocação de dados e metadados é rastreada separadamente. Verifique tanto o espaço livre comum quanto o uso do Btrfs:

df -hT /data
sudo btrfs filesystem usage -T /data

Se o sistema reportar No space left on devicefalhas de dispositivo ou erros estruturais no log do kernel, verifique o uso do Snapper antes de remover qualquer componente:

sudo snapper list

Exclua apenas os snapshots que sua política de retenção permite perder, usando sudo snapper delete SNAPSHOT_IDum valor para cada ID selecionado. Mantenha um snapshot válido anterior à atualização caso precise de uma opção de reversão; excluir snapshots recupera espaço, mas remove os pontos de recuperação. A limpeza pode não liberar espaço imediatamente e os snapshots não corrigem erros de E/S. Não execute um balanceamento para forçar um sistema de arquivos somente leitura a se tornar gravável; ele move dados e destina-se a problemas de alocação diagnosticados em um sistema de arquivos íntegro e gravável.

3. Leia o log do kernel antes de escolher uma opção de reparo.

Procure pelo primeiro erro relacionado ao Btrfs, dispositivo de bloco, controlador ou transporte, e não apenas pela mensagem final informando que o sistema de arquivos se tornou somente leitura:

sudo journalctl -k -b --no-pager | grep -Ei 'btrfs|I/O error|nvme|ata|scsi'

Mensagens sobre falhas de leitura, incompatibilidades de checksum, dispositivos ausentes ou erros de E/S apontam para uma solução diferente de uma simples roopção de montagem. Verifique as informações de integridade do disco, controlador, RAID/HBA, SAN ou disco virtual relatadas, bem como as informações do fornecedor. Corrija primeiro problemas de hardware ou conectividade instáveis. Se os dados forem importantes, minimize as gravações e providencie um backup ou uma imagem em nível de bloco com um administrador antes de tentar reparar o sistema de arquivos.

4. Escolha a recuperação menos arriscada que corresponda às evidências.

No SLES, os snapshots inicializáveis ​​usam a configuração raiz padrão do Snapper. A raiz deve ser Btrfs em um dispositivo, o carregador de inicialização deve suportá-la e somente o subvolume raiz é revertido. Verifique um candidato antes de confirmar; se inadequado, reinicie para o sistema atual ou para o ambiente de recuperação. Consulte o procedimento de reversão do Snapper no SLES 15 SP7 .

Quando verificações offline ou uma limpeza completa são apropriadas

Se o sistema de arquivos não montar ou se as mensagens do kernel sugerirem danos estruturais, inicialize o sistema de recuperação do SLES ou outro ambiente de recuperação adequado, identifique o dispositivo correto e certifique-se de que ele esteja desmontado antes de executar a verificação padrão somente leitura:

sudo btrfs check /dev/DEVICE

Use o dispositivo de bloco Btrfs real, não um ponto de montagem fictício. Uma verificação pode levar tempo e memória e relata descobertas estruturais; ela não garante o reparo. Não adicione essa opção --repaircomo uma próxima etapa de rotina. A documentação do Btrfs alerta que o reparo pode piorar a situação e deve ser usado somente com orientação especializada após a aceitação do risco para os dados. Consulte o suporte da SUSE ou um especialista em Btrfs quando a verificação relatar erros ou o dispositivo apresentar falhas de E/S.

Após o armazenamento estar estável e o sistema de arquivos montado em modo de leitura e gravação, sudo btrfs scrub start -B /dataé possível verificar os checksums. O comando scrub não é um verificador estrutural. Ele só pode reparar danos a partir de uma cópia redundante comprovadamente íntegra; em um layout de cópia única, ele detecta erros, mas não consegue reconstruir dados perdidos. Leia a documentação do comando scrub do Btrfs . Consulte também o guia de sistemas de arquivos do SLES 15 SP7 da SUSE , o artigo sobre recuperação do Btrfs da SUSE e o manual de verificação do Btrfs .

Verifique o resultado

Após a recuperação escolhida, verifique se o ponto de montagem possui as opções desejadas e se é possível realizar uma gravação segura:

findmnt -T /data -o TARGET,SOURCE,FSTYPE,OPTIONS
sudo touch /data/.rw-check && sudo rm /data/.rw-check

Para reverter um snapshot raiz, reinicie o sistema primeiro e confirme se o sistema padrão inicia normalmente. Em seguida, revise o novo log do kernel em busca de erros recorrentes do Btrfs ou do dispositivo. Um sinalizador de leitura/gravação por si só não garante a integridade do sistema: se os erros persistirem, interrompa as gravações e retorne ao diagnóstico do armazenamento.