Por que esse SSD está retornando dados inconsistentes, por que o arquivo de imagem de backup não corresponde à soma de verificação?

Question

Trata-se do SSD em um notebook. Parece que o SSD já está indo mal, possivelmente até mesmo corrompendo dados. Parece que retorna dados diferentes toda vez que é acessado enquanto não estiver em uso (veja abaixo para detalhes). Quais ferramentas podem ser usadas para confirmar essa suspeita?

Quando um disco rígido lentamente começa a morrer, geralmente há uma indicação clara na saída do SMART, uma ferramenta gráfica como gsmartcontrol realçaria um determinado valor em vermelho e um serviço como smartd poderia já ter gerado um aviso. Nesse ponto, o usuário ainda pode ter algum tempo para criar um backup antes de o disco começar a corromper os dados. É claro que, se a unidade já começou a corromper os dados, alguns arquivos desse backup podem ser danificados.

Parece que não há nenhum aviso claro na saída do SMART para este SSD, nenhum erro de kernel foi registrado no dmesg etc (por outro lado, o ecryptfs registrou erros). Em outras palavras, foi apenas por acaso que descobriu que esse SSD já pode estar tão ruim que está corrompendo dados mesmo quando não está em uso.
Depois de fazer um backup (1: 1 dd image) deste SSD (sda), descobri que a soma de verificação do arquivo de imagem não corresponde à soma de verificação do SSD. É claro que isso estava em um sistema ativo, então o SSD não estava montado, o que significa que seu conteúdo não poderia ter sido alterado durante o processo de backup.

Foi o que fiz para fazer a cópia de backup. "BUTTER" é onde eu montei uma unidade externa, que é formatada com o BTRFS para que eu possa descobrir erros de dados caso a unidade de backup também seja ruim (ao contrário da maioria dos sistemas de arquivos, o BTRFS tem checksums).

[root@localhost mnt]# time dd if=/dev/sda of=BUTTER/SSD.dd.img bs=400M && echo OK
610+1 records in
610+1 records out
256060514304 bytes (256 GB, 238 GiB) copied, 5188.27 s, 49.4 MB/s

real    86m28.726s
user    0m0.008s
sys 7m3.597s
OK

Eu criei uma soma de verificação MD5 do arquivo de imagem e outra do SDD e eles não coincidiram. Depois de repetir esse procedimento, percebi que a soma de verificação MD5 do SSD é diferente a cada vez .

[root@localhost mnt]# time dd if=/dev/sda bs=400M | md5sum >/tmp/MD5-again

610+1 records in
610+1 records out
256060514304 bytes (256 GB, 238 GiB) copied, 1059.87 s, 242 MB/s

real    17m39.904s
user    8m21.708s
sys 3m58.466s
[root@localhost mnt]# cat /tmp/MD5-again
24e71715359158f3ab38e748af93718c  -
[root@localhost mnt]# time dd if=/dev/sda bs=400M | md5sum >>/tmp/MD5-again
610+1 records in
610+1 records out
256060514304 bytes (256 GB, 238 GiB) copied, 1073.7 s, 238 MB/s

real    17m53.735s
user    8m28.494s
sys 4m23.993s
[root@localhost mnt]# cat /tmp/MD5-again
24e71715359158f3ab38e748af93718c  -
569d517626c1b7394acca0c4020c99bc  -

Novamente, o SSD nunca foi montado em nenhum ponto durante esse processo.

# mount | grep -c sda
0

Eu fiz um teste SMART, que não encontrou nada. Nenhum erro SMART é registrado.
Atributos SMART:

Modelo do dispositivo: SanDisk SD8TN8U256G1001

[root@localhost mnt]# smartctl -A /dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.16.3-301.fc28.x86_64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 4
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   100   100   ---    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   ---    Old_age   Always       -       3173
 12 Power_Cycle_Count       0x0032   100   100   ---    Old_age   Always       -       1117
170 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       0
171 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       0
172 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       0
173 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       37
174 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       41
178 Used_Rsvd_Blk_Cnt_Chip  0x0032   100   100   ---    Old_age   Always       -       0
180 Unused_Rsvd_Blk_Cnt_Tot 0x0033   100   100   010    Pre-fail  Always       -       100
184 End-to-End_Error        0x0033   100   100   097    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   ---    Old_age   Always       -       0
194 Temperature_Celsius     0x0022   056   062   ---    Old_age   Always       -       44 (Min/Max 13/62)
199 UDMA_CRC_Error_Count    0x0032   100   100   ---    Old_age   Always       -       0
233 Media_Wearout_Indicator 0x0033   093   100   001    Pre-fail  Always       -       15484248
234 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       11127
241 Total_LBAs_Written      0x0030   253   253   ---    Old_age   Offline      -       3192
242 Total_LBAs_Read         0x0030   253   253   ---    Old_age   Offline      -       66461
249 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       9346

O que está acontecendo?

    

Answer 1

Logo após postar esta pergunta, eu encontrei meu erro. Eu usei o Fedora XFCE como sistema live, o qual ativou automaticamente a partição de swap que por acaso está no SSD em questão. E, claro, enquanto o sistema live estava usando ativamente a partição swap no SSD, estava mudando o conteúdo do SSD.

[root@localhost mnt]# swapon --show
NAME      TYPE      SIZE   USED PRIO
/dev/sda3 partition   8G 103.3M   -2

Isso é um pouco estranho agora que eu já postei a pergunta. Mas vou deixá-lo lá, esperando que seja útil para alguém que possa estar cometendo o mesmo erro.

Tudo o que eu precisava fazer era desativar a partição de troca que foi montada anteriormente automaticamente:

[root@localhost mnt]# swapoff -a

Gostaria de salientar que a partição swap foi montada automaticamente quando inicializei o sistema live. Eu não queria que essa partição swap fosse montada. Gostaria de saber o que acontece se houver uma imagem de hibernação nessa partição de troca.

Depois de desabilitar a partição de swap indesejada, tudo funcionou como esperado. Usando os comandos mostrados acima, a soma de verificação do arquivo de imagem agora corresponde à soma de verificação do SSD. Em outras palavras, esse SSD não é ruim.