fsck não fsck (não é possível definir sinalizadores de superbloco)


12

Após um desligamento imundo em um dispositivo baseado em cartão SD, levei o cartão SD para fscko sistema de arquivos raiz. Isso levou a variações no seguinte:

e2fsck 1.43.1 (08-Jun-2016)
/dev/sdc2: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? no
Clear journal<y>? no
e2fsck: unable to set superblock flags on /dev/sdc2

Aqui eu respondi "não" nas duas vezes, mas não há uma sequência de sim / não que não leve imediatamente ao mesmo resultado.

O sistema de arquivos pode ser montado e, sob inspeção casual, parece bom; Ele também funciona bem no dispositivo, e esse é o sistema de arquivos raiz (na verdade, não foi muito bom, veja os comentários; tente alguns diretórios corrompidos irremediavelmente).

Eu tinha dda partição (8 GB) em um arquivo e tentei fsck nisso. Curiosamente:

e2fsck 1.43.1 (08-Jun-2016)
plush.rootfs: recovering journal
Clearing orphaned inode 18290 (uid=0, gid=0, mode=0100644, size=34096)
Clearing orphaned inode 18270 (uid=0, gid=0, mode=0100644, size=38916)
Clearing orphaned inode 18250 (uid=0, gid=0, mode=0100644, size=1128076)
Clearing orphaned inode 11411 (uid=0, gid=0, mode=0100644, size=293108)
Setting free inodes count to 406127 (was 408580)
Setting free blocks count to 1305622 (was 1347486)
plush.rootfs: clean, 60209/466336 files, 604906/1910528 blocks (check after next mount)

Uma fscklimpeza subsequente passada, a imagem pode ser montada e, fsck -fdepois disso, também passa.

Mas o sistema de arquivos no cartão a partir do qual a imagem de cópia em bloco não processada foi criada ainda tem o mesmo problema - exceto que o systemd-fsckque ocorre durante a inicialização registra o sistema de arquivos como "limpo". Posteriormente, porém, um desligamento adequado, retirando o cartão e tentando fscknovamente de outra caixa apresenta o mesmo erro.

Sempre que o original é montado em outra máquina, o syslog observa:

kernel: EXT4-fs (sdc2): 4 orphan inodes deleted
kernel: EXT4-fs (sdc2): recovery complete

Como tenho tudo feito em backup, estou aberto a tentar qualquer coisa aqui. Eu poderia simplesmente esquecer isso e recuperar a partição da imagem aparentemente fixa, mas isso não parece uma solução muito satisfatória, pois significa assumir que o fsck falhou criptograficamente na solução de um pequeno problema de aparência.

Eu suspeito que isso vai se transformar em uma pergunta de "solicitação de documentação oficial" sobre coisas como precisa de recovery_flag (ou apenas a pergunta "O que isso significa?"), Para que quaisquer sugestões nesse sentido sejam apreciadas.


Alguma coisa no log do kernel sobre erros de dispositivo? Esta não seria a primeira vez que um cartão SD de repente se tornaria somente leitura.
precisa

@ MarkPlotnick Não, e é gravável. A última coisa no log anterior ao problema foi reiniciar o sistema (o dispositivo fica sem cabeça e deixa de responder após um longo período apt upgrade). Depois disso, ele registra uma inicialização normal - e o systemd-fsck diz "clean" (vou editar isso em), mas tentar o fsck fora desse contexto ainda falha.
Goldilocks

Seu fsck na cópia limpou 4 inodes, mas corrigiu a contagem de inodes livres, reduzindo-a em 2453 inodes! Isso é enorme. Verifique se o dispositivo está recebendo energia suficiente.
meuh 4/12/16

@ meuh eu aviso sempre que ele é montado no syslog da caixa grande se refere aos 4 inodes (editados acima). Algumas coisas no fs acabaram sendo confusas (módulos de kernel atualizados! \ O /), então eu queimei uma nova placa e continuarei com a antiga, caso eu tenha uma chance de investigar mais isso. Não é exatamente novo - um cartão sem marca de classe 10, em uso leve, 24 horas por dia, sete dias por semana, possivelmente por alguns anos, então ... Acho que não há como verificar se um cartão SD está definitivamente desativado. , mas acho que pode ser isso. A energia deve estar boa, mas pode ser duvidosa sob certas condições.
Goldilocks

2
Não é realmente ruim quando a própria ferramenta que deveria corrigir o seu problema não funciona devido à natureza do problema? Conclusão: A ferramenta está ruim e deve ser corrigida.
Marc.2377

Respostas:


11

Acabei de encontrar este mesmo problema. Depois de depurar o problema com o e2fsckmantenedor, percebemos que o cartão SD estava quebrado. Aceitava gravações sem erro, mas na verdade não estava gravando os dados no cartão. O cartão SD foi efetivamente somente leitura.

Parece que o cartão entrou em algum tipo de modo à prova de falhas, onde os dados ainda podiam ser lidos, mas nada gravado.

A e2fsckmensagem unable to set superblock flagssignifica que tentou gravar no superbloco para marcar o diário como processado, o que aconteceu sem erros, mas quando foi ler o superbloco novamente, ainda indicava que o diário precisava ser reproduzido novamente. Em outras palavras, as alterações gravadas no superbloco não foram salvas na mídia de armazenamento.

O cartão que estou usando que tem esse problema é um microSD Samsung Evo de 16GB, que menciono para o caso de ser um problema comum com esses cartões.

Consegui testar isso usando ddpara escrever 4096 bytes /dev/zerono cartão no bloco 0, depois li novamente no cartão e, em vez de obter todos os zeros como deveria, ainda obtive o superbloco ext4 original inalterado.

Agora, estou no processo de mover os dados para um novo cartão e ver se consigo uma substituição da Samsung, que parece oferecer uma garantia de 10 anos em cartões SD.

ATUALIZAÇÃO: A Samsung substituiu o cartão de 16GB por um de 32GB da mesma série Evo, então acho que não posso reclamar muito!


"onde os dados ainda podem ser lidos, mas nada escrito" -> O fs era gravável.
goldilocks

@ goldilocks: Parece que o seu superbloco fs pode não ter sido gravável. Além disso, meus fs pareciam graváveis ​​graças ao armazenamento em cache, foi somente após a desmontagem e remontagem que notei que quaisquer alterações foram perdidas.
Malvineous

Não era uma ilusão devido ao cache.
Goldilocks

7

Sei que esse é um tópico antigo, mas achei que ofereceria algumas dicas.

Parece que é assim que os cartões SD morrem naturalmente. O número de ciclos de leitura / gravação que os cartões SD podem suportar é substancialmente menor do que a maioria dos outros meios considerados 'leitura / gravação'. Quando isso acabar, o cartão entrará no modo somente leitura, mas não o informará. Muitas coisas pensam que estão gravando no cartão graças ao cache do sistema operacional etc., mas nada fica.

Uma ótima maneira de matar um cartão SD é montá-lo como uma partição swap ou algo que exige muita leitura / gravação. Você ficaria surpreso com a rapidez com que você pode matar um cartão dessa maneira. Descobri que a execução do knoppix em um cartão SD ou pen drive USB durará apenas um mês ou dois, dependendo da qualidade do cartão e da intensidade do uso do knoppix. (Desde então, mudei para rodar o knoppix em uma unidade USB SSD que já dura alguns anos).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.