Corrigir um erro de sistema de arquivos Btrfs somente leitura no SUSE Linux Enterprise

Ao tentar salvar um arquivo ou atualizar um serviço no SUSE Linux Enterprise Server (SLES), o Linux responde com a mensagem “Sistema de arquivos somente leitura”. Essa mensagem pode significar que o ponto de montagem foi configurado deliberadamente como somente leitura, que você inicializou o sistema a partir de um snapshot do Snapper em modo somente leitura ou que o Btrfs detectou um problema e parou de aceitar gravações para proteger o volume. Essas causas exigem soluções diferentes. Comece identificando qual sistema de arquivos e ponto de montagem estão envolvidos; não force uma remontagem nem execute um comando de reparo antes de verificar os logs do kernel e proteger os dados importantes.

O que significa o erro

O Btrfs é um sistema de arquivos Linux do tipo copy-on-write, usado por padrão como sistema de arquivos raiz do SLES em muitas instalações padrão. Um subvolume Btrfs é uma parte independente e montável de um sistema de arquivos; um snapshot é uma cópia pontual de um subvolume que compartilha blocos de dados inalterados. O Snapper e o menu de inicialização do SLES podem usar snapshots para recuperar o sistema de alterações. Inicializar um snapshot monta intencionalmente as partes incluídas em modo somente leitura. Além disso, o Btrfs pode alternar para o modo somente leitura após detectar certos erros estruturais para evitar novas gravações. A SUSE documenta o comportamento dos snapshots em seu guia do Snapper para SLES 15 SP7 ; o projeto Btrfs explica que as verificações estruturais do sistema de arquivos podem alternar um volume para o modo somente leitura para evitar danos adicionais em sua documentação do tree-checker . Os rótulos exatos do menu e as opções de recuperação disponíveis podem variar de acordo com o service pack do SLES e o layout de armazenamento.

Um problema de permissões é diferente. "Permissão negada" geralmente indica problemas de propriedade ou controle de acesso; "Sistema de arquivos somente leitura" (frequentemente exibido como EROFS) indica o estado do sistema de arquivos ou subvolume. Alterar as permissões de um arquivo com chmodnão tornará uma montagem somente leitura gravável.

Antes de alterar qualquer coisa

Se este for um servidor de produção, um volume de banco de dados ou a única cópia de dados importantes, entre em contato com o administrador do sistema e confirme o backup antes de tentar a recuperação. Quando o sistema ainda estiver legível, copie os arquivos mais importantes para um armazenamento separado e íntegro, se puder fazê-lo sem sobrecarregar um dispositivo com falhas. O Btrfs pode ter alterações de metadados recentes apenas na memória após um erro crítico; desmontar ou reiniciar o sistema pode perder essas alterações não confirmadas. Se os logs mencionarem erros de E/S, desaparecimento de dispositivos ou reinicializações repetidas, priorize a integridade do armazenamento e a proteção dos dados em vez de restaurar as gravações.

Não execute btrfs check --repairesse procedimento como primeiro passo de rotina. O projeto Btrfs alerta que o modo de reparo pode causar danos e não consegue corrigir todos os tipos de corrupção. Também não force repetidamente uma remontagem de leitura e gravação: isso pode falhar imediatamente se o kernel tiver protegido o sistema de arquivos por algum motivo.

Passo 1: Identifique o suporte afetado

Use o caminho onde a gravação falhou. Por exemplo, se um serviço não consegue gravar em /srv/app, inspecione esse caminho em vez de presumir que o problema está no sistema de arquivos raiz:

findmnt -T /srv/app -o TARGET,SOURCE,FSTYPE,OPTIONS

Substitua /srv/apppelo arquivo ou diretório afetado. Verifique a saída para a origem Btrfs, o destino da montagem e uma opção de `--mount` roou ` --mount` rw. O destino pode ser ` //usr/local/bin`, uma montagem de dados separada ou um subvolume. Anote a origem e o destino antes de continuar. Se o comando reportar outro tipo de sistema de arquivos, as etapas específicas do Btrfs não se aplicam a esse caminho.

Verifique as mensagens do kernel da inicialização atual para descobrir o motivo pelo qual o sistema de arquivos se tornou somente leitura:

sudo journalctl -k -b --no-pager | grep -iE 'btrfs|I/O error|read-only|readonly'

Procure por erros do Btrfs ou mensagens de "somente leitura forçado", erros de checksum ou de árvore de arquivos, falhas de E/S do dispositivo e desconexões do dispositivo. Uma linha de log é uma pista, não um diagnóstico completo. Salve as mensagens e os registros de data e hora relevantes antes de reiniciar, pois os logs podem ser úteis para a equipe de suporte de armazenamento ou hardware.

Etapa 2: Verifique se há um snapshot intencionalmente somente leitura.

Se o servidor foi iniciado a partir de um snapshot inicializável no GRUB, os arquivos incluídos nesse snapshot são somente leitura por padrão. Este é um ambiente de recuperação para verificar um estado anterior do sistema; não se trata automaticamente do sistema restaurado permanentemente. Confirme a entrada de inicialização com o administrador, reinicie o servidor e selecione a entrada padrão do SLES caso a inicialização do snapshot tenha sido acidental. A SUSE documenta que a inicialização de um snapshot monta as partes do sistema de arquivos incluídas como somente leitura e descreve o procedimento de reversão separadamente em seu guia de recuperação do SLES 15 SP7 Snapper .

Um snapshot específico pode ser somente leitura mesmo que o sistema de arquivos pai esteja montado em modo de leitura e gravação. Se você estiver trabalhando intencionalmente com um snapshot, inspecione-o sem alterá-lo:

sudo btrfs property get -t subvol /path/to/subvolume ro

Substitua o caminho pelo caminho de montagem do subvolume. Um resultado ro=trueconfirma que a propriedade do subvolume é somente leitura; a documentação de referência de propriedades do Btrfs registra essa flag. Não altere simplesmente um snapshot de backup gerenciado ou recebido pelo Snapper para leitura/gravação: o status somente leitura pode fazer parte das premissas de rollback ou backup incremental. Use um fluxo de trabalho do Snapper compatível ou crie um subvolume gravável separado quando essa for a tarefa pretendida.

Etapa 3: Verifique a configuração de montagem e o status do armazenamento.

Se findmntos relatórios roe os logs não mostrarem erros de Btrfs ou de E/S, inspecione a entrada de montagem correspondente em /etc/fstab. Uma montagem pode ter sido configurada deliberadamente como somente leitura para recuperação, uma imagem de dispositivo ou uma política de proteção de dados. Altere a configuração somente após confirmar o estado pretendido com o proprietário do serviço. Verifique também se o sistema usa uma implantação transacional ou de raiz somente leitura: o SLES documenta essas configurações e seu fluxo de trabalho de manutenção em seu guia de atualizações transacionais . Se a entrada for explicitamente destinada à gravação, o dispositivo estiver íntegro e o caminho não for um snapshot somente leitura, um administrador poderá tentar uma remontagem temporária.

sudo mount -o remount,rw /mountpoint

Substitua /mountpointpelo destino exato mostrado por findmnt. Isso não diagnostica nem repara corrupção. Se falhar, retornar um erro ou os logs do kernel mostrarem problemas de armazenamento, pare e passe para o planejamento de recuperação em vez de tentar novamente com mais opções.

Para um possível problema de capacidade, verifique a alocação do Btrfs e o status do dispositivo:

sudo btrfs filesystem usage /mountpoint
sudo btrfs filesystem show /mountpoint

A SUSE observa que resumos comuns de espaço livre em disco podem ser enganosos no Btrfs, pois dados e metadados são alocados separadamente. Os snapshots do Snapper também podem reter uma quantidade substancial de espaço. No entanto, a mensagem "Sem espaço disponível no dispositivo" não é idêntica a um erro de somente leitura do Btrfs; identifique qual mensagem o aplicativo realmente recebeu. Não exclua snapshots apenas para testar uma teoria. Confirme o que eles contêm e siga a política de retenção aplicável primeiro. Consulte o guia de solução de problemas do sistema de arquivos do SLES 15 SP7 .

Etapa 4: Decida se o sistema de arquivos precisa de recuperação.

Se erros do Btrfs aparecerem no log do kernel, o dispositivo estiver ausente ou a remontagem for recusada, preserve os logs e providencie um backup verificado ou um snapshot em nível de armazenamento antes de realizar qualquer reparo. Para um volume de dados que não seja o raiz, planeje uma janela de manutenção e desmonte-o antes de realizar verificações offline. Para o sistema de arquivos raiz, utilize a mídia de instalação ou de recuperação do SUSE e siga o procedimento específico para a versão do SLES e a assinatura de erro. Não tente adivinhar o nome do dispositivo: um sistema de arquivos Btrfs pode abranger vários dispositivos, portanto, primeiro identifique todos os membros e os identificadores de montagem ou de dispositivo corretos.

O guia de administração do SLES 15 SP7 da SUSE possui uma seção específica para partições Btrfs raiz que não podem ser montadas. Nela, são discutidas opções de recuperação para essa falha de inicialização. Essas instruções não significam que todos os sistemas de arquivos somente leitura montados devam ter seus logs apagados. O manual do btrfs-rescue explica que btrfs rescue zero-logele serve para determinadas falhas de reprodução de logs durante a montagem e pode descartar alterações desde a última transação confirmada. Use-o somente quando o erro registrado corresponder ao caso documentado e o plano de recuperação levar em conta a possível perda de dados.

btrfs checkPor padrão, o btrfs-check é executado em modo somente leitura em um sistema de arquivos desmontado. Mantenha-o assim para a avaliação inicial e compartilhe a saída com o suporte da SUSE ou com um especialista em Btrfs. O manual do btrfs-check adverte explicitamente contra o uso --repairsem a orientação de um usuário ou desenvolvedor experiente. Nunca execute um verificador offline em um sistema de arquivos montado e em processo de alteração.

Etapa 5: Verificar recuperação

Após a correção da causa, reinicie o sistema somente quando o plano de recuperação assim o exigir. Em seguida, utilize o sistema findmnt -T /path -o TARGET,SOURCE,FSTYPE,OPTIONSnovamente e confirme se a montagem pretendida é de leitura e gravação. Verifique o log do kernel em busca de novos erros de Btrfs ou de E/S. Por fim, verifique se o serviço ou aplicativo afetado consegue operar normalmente e confirme se o backup permanece disponível. Uma remontagem bem-sucedida por si só não comprova que o armazenamento está íntegro.

Se o sistema de arquivos retornar ao modo somente leitura, o dispositivo for desconectado ou os erros persistirem, interrompa as gravações e envie os logs salvos, findmnta saída, a lista de dispositivos Btrfs, o nível do service pack do SLES e os detalhes do controlador de armazenamento. Essas evidências ajudam a distinguir um snapshot intencional ou uma opção de montagem de danos à mídia, à conexão, ao driver ou ao sistema de arquivos — e evitam que um estado somente leitura de proteção se transforme em um problema de recuperação maior.