Atualizar

Question

Não sei como forçar o fsck usando a solução que você está tentando, mas posso sugerir uma solução alternativa:

Use tune2fse limite o valor a remontagens e carimbos de data/hora muito baixos

# To see current settings
sudo tune2fs -l /dev/sda4
# To alter it
sudo tune2fs -c 1 -i 1d /dev/sda4

Isso forçará a verificação a cada 1 remontagem ou a cada 1 dia desde a última verificação, o que acontecer primeiro.

Verifique SMART

Como outros já disseram, isso é apenas um curativo para problemas de HW. Às vezes o HDD está morrendo, outras vezes é um problema de HW não relacionado (realize um memtest), outras vezes é apenas um cabo SATA solto (desconecte e conecte-o novamente em ambas as extremidades, se isso não resolver, tente outro cabo) .

Cuidado, na pior das hipóteses, a PSU está com defeito e danificando o restante do HW (nesse caso, substituir o HDD apenas resolverá o problema temporariamente porque, com o tempo, o novo HDD será danificado pela PSU). Verifique se as tensões estão dentro dos níveis aceitáveis.

Postando a saída do smart:

sudo smartctl -a /dev/sda

Pode ajudar a diagnosticar o que pode estar acontecendo.

Atualizar

Também não sei por que você não pode executar o fsck via tune2fs.

Mas eu vi seu SMART. Segundo ele, seu disco está envelhecendo, mas parece estar saudável.

O problema pode estar em outro lugar, como no cabo SATA.

Se você não consegue fazer o fsck funcionar, tudo o que posso sugerir é inicializar a partir de um liveUsb e executar o comando manualmente.

Atualização 2

OK, você postou as mensagens dmseg.Temos informações conflitantes provenientes do SMART e do SO, então vou escrever em detalhes.

Blocos ruins

A SMART diz que suas unidades apresentam bloqueios defeituosos. Isso é normal para qualquer SSD à medida que envelhece, e a unidade realocará os dados em blocos sobressalentes. Quando ficar sem peças sobressalentes, a unidade precisará ser substituída.

SMART diz que quantidade de badblocks está dentro do “normal”: Os atributos mais importantes para ver aqui são Reallocated_Sector_Cte Runtime_Bad_Block.

Ele diz que detectou 311 blocos defeituosos e realocou 311 em blocos sobressalentes. Isso é bom. Se houvesse 311 blocos defeituosos, mas apenas 310 realocações, isso significa que os dados em um dos blocos foram perdidos.

O que importa é o valor “normalizado” (038). É assim que o fabricante informa o que considera normal.

Um valor onde 100 significa perfeito e 0 significa muito ruim. No momento são 38, o que significa “isso está ficando ruim”; mas o fabricante diz que está tudo bem, desde que esse valor esteja acima de 010 (o THRESHold).

Aqui temos nossa primeira informação conflitante: Used_Rsvd_Blk_Cnt_Totdiz que a reserva não foi tocada, apesar de ter blocos ruins. Não faz sentido.

Mas eu não ficaria surpreso se o firmware simplesmente não rastreasse esse valor, apesar de reportá-lo, então vamos ignorar isso por enquanto.

Nivelamento de desgaste

Este é o atributo mais problemático de ler. Wear_Leveling_Countdiz que é 001. Normalmente, um valor de 1 significa que sua unidade está morta e deve ser substituída o mais rápido possível.

Isso significa que ficaram sem blocos sobressalentes. Mas houve bugs de firmware em que esse atributo é relatado de trás para frente e um valor 1 significa que a unidade está com 99% de integridade.

Usando umCalculadora TBWInseri seu número de LBAs gravados + tamanho do setor 512 e descobri que sua unidade tem 77,43TiB gravados. De acordo com o Google, seu modelo deve ter 150 TBW, entãodeveainda será viável.

Receio que a melhor solução aqui seja ativar uma caixa do Windows e executarCrystalDiskInfoque explica esses bugs de firmware (usando um banco de dados interno) e reportará uma avaliação de saúde muito precisa.

Dado que o seu smart diz, SMART overall-health self-assessment test result: PASSEDestou inclinado a acreditar que ele quer dizer 99%, em vez de 1%.

Mas se eu estiver errado podemos parar por aqui, o disco deve ser substituído.

Problemas de cabo / problemas de placa-mãe

Os erros no dmesg do Linux basicamente dizem que ele tentou ler um setor e obteve dados incorretos.

O kernel ainda diz que tentou ler o setor 235602696 duas vezes e obteve dados diferentes:

28 00 0e 0b 03 08 00 002000
28 00 0e 0b 03 08 00 000800.

Se o disco disser que não há erros, mas o sistema operacional disser que há; então os dados foram corrompidos em trânsito. Normalmente isso indica:

O cabo SATA está mal conectado
O cabo SATA está danificado
O cabo de alimentação está mal conectado
O cabo de alimentação está danificado
Falha no barramento da placa-mãe
Falha na fonte de alimentação
Falha de RAM

Mas é aqui que temosnossa segunda fonte de informações conflitantes: UDMA_CRC_Error_Counté 0.

Isso significa que o disco nunca detectou um único erro causado por um cabo defeituoso/solto ou por um barramento da placa-mãe defeituoso.

Isto é muito improvável. A SMART diz que o disco está bom, os comandos que chegam do sistema operacional para o disco nunca são corrompidos por fiação incorreta; ainda assim, o sistema operacional leu o mesmo setor duas vezes e obteve um byte diferente.

A única coisa que consigo pensar que tornaria isso possível é se você tiver uma RAM ruim.Ou um problema de cabo extremamente improvável, onde todos os dados que vão para o disco nunca são corrompidos, mas os dados que saem dele são corrompidos.

Curso de ação

Meu instinto me diz que o disco está ruim. Mas:

Faça backup de todos os dados em outro disco. Em uma execução LiveUSB (e uma unidade USB externa grande o suficiente):

sudo apt install zstd

# To backup
sudo zstd -16v < /dev/sda > /media/external_disk/backup_file.zst

# To restore (don't do that on step 1, see step 5)
sudo zstdcat -v /media/external_disk/backup_file.zst > /dev/sda

Faça backup dos dados novamente, mas desta vez apenas com uma cópia normal dos arquivos (se o disco morrer, é muito mais fácil recuperar a partir de um backup simples do que tentar montar em loop uma imagem zstd compactada de um disco e ler os arquivos a partir disso)
Reinicie e execute um memtest para descartar erros de RAM
Desligue, abra o gabinete e desconecte e conecte novamente os cabos SATA e de alimentação (para a unidade). Verifique se eles não estão danificados. Possivelmente substitua-os.
Inicialize na unidade LiveUSB novamente e execute uma limpeza segura do disco. Se houver algum problema acontecendo com sua unidade, talvez isso a redefina de volta para uma condição de funcionamento (ou talvez resulte no último comando executado se o disco estiver além da salvação). Isso deve levar vários minutos:

sudo blkdiscard -s /dev/sda

Se tudo correu bem até agora, restaure seu backup com o sudo zstdcatcomando da etapa 1.

Se o disco ainda apresentar problemas e o memtest for bem-sucedido, pessoalmente eu consideraria o disco ruim.

Não podemos ignorar que um valor de 038 Reallocated_Sector_Ctsignifica que as coisas estão piorando, apesar do fabricante dizer que ainda não está “tão” ruim.

Ah! Importante: Se em algum momento você deixou o disco desligado por mais de 3 meses; este cenário é bem possível. Apesar da crença popular, as células NAND podem perder seu armazenamento se ficarem sem energia por muito tempo ("muito tempo" pode variar de 7 dias a 7 anos; mas o caso mais comum é de 3 meses). Principalmente se forem velhos.

Se isso aconteceu com você, basta executar as etapas acima: faça backup dos dados, limpe o disco com segurança, restaure o backup.

Boa sorte.

Answer 1

Não sei como forçar o fsck usando a solução que você está tentando, mas posso sugerir uma solução alternativa:

Use tune2fse limite o valor a remontagens e carimbos de data/hora muito baixos

# To see current settings
sudo tune2fs -l /dev/sda4
# To alter it
sudo tune2fs -c 1 -i 1d /dev/sda4

Isso forçará a verificação a cada 1 remontagem ou a cada 1 dia desde a última verificação, o que acontecer primeiro.

Verifique SMART

Como outros já disseram, isso é apenas um curativo para problemas de HW. Às vezes o HDD está morrendo, outras vezes é um problema de HW não relacionado (realize um memtest), outras vezes é apenas um cabo SATA solto (desconecte e conecte-o novamente em ambas as extremidades, se isso não resolver, tente outro cabo) .

Cuidado, na pior das hipóteses, a PSU está com defeito e danificando o restante do HW (nesse caso, substituir o HDD apenas resolverá o problema temporariamente porque, com o tempo, o novo HDD será danificado pela PSU). Verifique se as tensões estão dentro dos níveis aceitáveis.

Postando a saída do smart:

sudo smartctl -a /dev/sda

Pode ajudar a diagnosticar o que pode estar acontecendo.

Atualizar

Também não sei por que você não pode executar o fsck via tune2fs.

Mas eu vi seu SMART. Segundo ele, seu disco está envelhecendo, mas parece estar saudável.

O problema pode estar em outro lugar, como no cabo SATA.

Se você não consegue fazer o fsck funcionar, tudo o que posso sugerir é inicializar a partir de um liveUsb e executar o comando manualmente.

Atualização 2

OK, você postou as mensagens dmseg.Temos informações conflitantes provenientes do SMART e do SO, então vou escrever em detalhes.

Blocos ruins

A SMART diz que suas unidades apresentam bloqueios defeituosos. Isso é normal para qualquer SSD à medida que envelhece, e a unidade realocará os dados em blocos sobressalentes. Quando ficar sem peças sobressalentes, a unidade precisará ser substituída.

SMART diz que quantidade de badblocks está dentro do “normal”: Os atributos mais importantes para ver aqui são Reallocated_Sector_Cte Runtime_Bad_Block.

Ele diz que detectou 311 blocos defeituosos e realocou 311 em blocos sobressalentes. Isso é bom. Se houvesse 311 blocos defeituosos, mas apenas 310 realocações, isso significa que os dados em um dos blocos foram perdidos.

O que importa é o valor “normalizado” (038). É assim que o fabricante informa o que considera normal.

Um valor onde 100 significa perfeito e 0 significa muito ruim. No momento são 38, o que significa “isso está ficando ruim”; mas o fabricante diz que está tudo bem, desde que esse valor esteja acima de 010 (o THRESHold).

Aqui temos nossa primeira informação conflitante: Used_Rsvd_Blk_Cnt_Totdiz que a reserva não foi tocada, apesar de ter blocos ruins. Não faz sentido.

Mas eu não ficaria surpreso se o firmware simplesmente não rastreasse esse valor, apesar de reportá-lo, então vamos ignorar isso por enquanto.

Nivelamento de desgaste

Este é o atributo mais problemático de ler. Wear_Leveling_Countdiz que é 001. Normalmente, um valor de 1 significa que sua unidade está morta e deve ser substituída o mais rápido possível.

Isso significa que ficaram sem blocos sobressalentes. Mas houve bugs de firmware em que esse atributo é relatado de trás para frente e um valor 1 significa que a unidade está com 99% de integridade.

Usando umCalculadora TBWInseri seu número de LBAs gravados + tamanho do setor 512 e descobri que sua unidade tem 77,43TiB gravados. De acordo com o Google, seu modelo deve ter 150 TBW, entãodeveainda será viável.

Receio que a melhor solução aqui seja ativar uma caixa do Windows e executarCrystalDiskInfoque explica esses bugs de firmware (usando um banco de dados interno) e reportará uma avaliação de saúde muito precisa.

Dado que o seu smart diz, SMART overall-health self-assessment test result: PASSEDestou inclinado a acreditar que ele quer dizer 99%, em vez de 1%.

Mas se eu estiver errado podemos parar por aqui, o disco deve ser substituído.

Problemas de cabo / problemas de placa-mãe

Os erros no dmesg do Linux basicamente dizem que ele tentou ler um setor e obteve dados incorretos.

O kernel ainda diz que tentou ler o setor 235602696 duas vezes e obteve dados diferentes:

28 00 0e 0b 03 08 00 002000
28 00 0e 0b 03 08 00 000800.

Se o disco disser que não há erros, mas o sistema operacional disser que há; então os dados foram corrompidos em trânsito. Normalmente isso indica:

O cabo SATA está mal conectado
O cabo SATA está danificado
O cabo de alimentação está mal conectado
O cabo de alimentação está danificado
Falha no barramento da placa-mãe
Falha na fonte de alimentação
Falha de RAM

Mas é aqui que temosnossa segunda fonte de informações conflitantes: UDMA_CRC_Error_Counté 0.

Isso significa que o disco nunca detectou um único erro causado por um cabo defeituoso/solto ou por um barramento da placa-mãe defeituoso.

Isto é muito improvável. A SMART diz que o disco está bom, os comandos que chegam do sistema operacional para o disco nunca são corrompidos por fiação incorreta; ainda assim, o sistema operacional leu o mesmo setor duas vezes e obteve um byte diferente.

A única coisa que consigo pensar que tornaria isso possível é se você tiver uma RAM ruim.Ou um problema de cabo extremamente improvável, onde todos os dados que vão para o disco nunca são corrompidos, mas os dados que saem dele são corrompidos.

Curso de ação

Meu instinto me diz que o disco está ruim. Mas:

Faça backup de todos os dados em outro disco. Em uma execução LiveUSB (e uma unidade USB externa grande o suficiente):

sudo apt install zstd

# To backup
sudo zstd -16v < /dev/sda > /media/external_disk/backup_file.zst

# To restore (don't do that on step 1, see step 5)
sudo zstdcat -v /media/external_disk/backup_file.zst > /dev/sda

Faça backup dos dados novamente, mas desta vez apenas com uma cópia normal dos arquivos (se o disco morrer, é muito mais fácil recuperar a partir de um backup simples do que tentar montar em loop uma imagem zstd compactada de um disco e ler os arquivos a partir disso)
Reinicie e execute um memtest para descartar erros de RAM
Desligue, abra o gabinete e desconecte e conecte novamente os cabos SATA e de alimentação (para a unidade). Verifique se eles não estão danificados. Possivelmente substitua-os.
Inicialize na unidade LiveUSB novamente e execute uma limpeza segura do disco. Se houver algum problema acontecendo com sua unidade, talvez isso a redefina de volta para uma condição de funcionamento (ou talvez resulte no último comando executado se o disco estiver além da salvação). Isso deve levar vários minutos:

sudo blkdiscard -s /dev/sda

Se tudo correu bem até agora, restaure seu backup com o sudo zstdcatcomando da etapa 1.

Se o disco ainda apresentar problemas e o memtest for bem-sucedido, pessoalmente eu consideraria o disco ruim.

Não podemos ignorar que um valor de 038 Reallocated_Sector_Ctsignifica que as coisas estão piorando, apesar do fabricante dizer que ainda não está “tão” ruim.

Ah! Importante: Se em algum momento você deixou o disco desligado por mais de 3 meses; este cenário é bem possível. Apesar da crença popular, as células NAND podem perder seu armazenamento se ficarem sem energia por muito tempo ("muito tempo" pode variar de 7 dias a 7 anos; mas o caso mais comum é de 3 meses). Principalmente se forem velhos.

Se isso aconteceu com você, basta executar as etapas acima: faça backup dos dados, limpe o disco com segurança, restaure o backup.

Boa sorte.

Atualizar

Responder1

Verifique SMART

Atualizar

Atualização 2

Blocos ruins

Nivelamento de desgaste

Problemas de cabo / problemas de placa-mãe

Curso de ação

informação relacionada