Dlaczego ten dysk SSD zwraca niespójne dane, dlaczego plik obrazu kopii zapasowej nie odpowiada sumie kontrolnej?

Chodzi o dysk SSD w notatniku. Wygląda na to, że dysk SSD już się psuje, być może nawet psuje dane. Wygląda na to, że zwraca różne dane za każdym razem, gdy jest uzyskiwany dostęp, gdy nie jest używany (szczegółowe informacje znajdują się poniżej). Jakich narzędzi można użyć do potwierdzenia tego podejrzenia?

Gdy dysk twardy powoli zaczyna umierać, na wyjściu SMART zwykle pojawia się wyraźne wskazanie, narzędzie graficzne, gsmartcontrolktóre podświetliłoby określoną wartość na czerwono, a usługa taka smartdmogła już wygenerować ostrzeżenie. W tym momencie użytkownik może mieć jeszcze trochę czasu na utworzenie kopii zapasowej, zanim dysk zacznie uszkadzać dane. Oczywiście, jeśli dysk już zaczął uszkadzać dane, niektóre pliki w kopii zapasowej mogą zostać uszkodzone.

Wydaje się, że nie ma wyraźnego ostrzeżenia na wyjściu SMART dla tego dysku SSD, żadne błędy jądra nie zostały zarejestrowane w dmesg itp. (Z drugiej strony ecryptfs zarejestrował błędy). Innymi słowy, tylko przypadkowo odkryto, że ten dysk SSD może być już tak zły, że powoduje uszkodzenie danych, nawet gdy nie jest używany.
Po utworzeniu kopii zapasowej (obraz 1: 1 dd) tego dysku SSD (sda) odkryłem, że suma kontrolna pliku obrazu nie zgadza się z sumą kontrolną dysku SSD. Oczywiście było to w systemie na żywo, więc dysk SSD nie został zamontowany, co oznacza, że ​​jego zawartość nie mogła ulec zmianie podczas procesu tworzenia kopii zapasowej.

To właśnie zrobiłem, aby wykonać kopię zapasową. „MASŁO” to miejsce, w którym zamontowałem dysk zewnętrzny sformatowany w systemie BTRFS, dzięki czemu będę mógł dowiedzieć się o błędach danych w przypadku awarii dysku zapasowego (w przeciwieństwie do większości innych systemów plików, BTRFS ma sumy kontrolne).

[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

Utworzyłem sumę kontrolną MD5 pliku obrazu i inną z SDD i nie pasowały. Po powtórzeniu tej procedury zdałem sobie sprawę, że suma kontrolna MD5 dysku SSD jest za każdym razem inna .

[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  -

Ponownie dysk SSD nigdy nie był montowany w żadnym momencie tego procesu.

# mount | grep -c sda
0

Przeprowadziłem test SMART, który niczego nie znalazł. Nie jest rejestrowany żaden błąd SMART.
Atrybuty SMART:

Model urządzenia: 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

Co się dzieje?

Zaraz po opublikowaniu tego pytania znalazłem swój błąd. Użyłem Fedory XFCE jako systemu na żywo, który automatycznie włączył partycję wymiany, która akurat znajduje się na danym dysku SSD. I oczywiście, gdy system na żywo aktywnie korzystał z partycji wymiany na dysku SSD, zmieniał w ten sposób zawartość dysku SSD.

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

To trochę dziwne, skoro już opublikowałem pytanie. Ale zostawię to tam, mając nadzieję, że przyda się komuś, kto może popełnić ten sam błąd.

Wszystko, co musiałem zrobić, to wyłączyć partycję wymiany, która wcześniej była automatycznie montowana:

[root@localhost mnt]# swapoff -a

Chciałbym zaznaczyć, że partycja wymiany została zamontowana automatycznie podczas uruchamiania systemu Live. Nie chciałem montować partycji wymiany. Zastanawiam się, co się stanie, jeśli na partycji wymiany pojawi się hibernacja.

Po wyłączeniu niechcianej partycji wymiany wszystko działało zgodnie z oczekiwaniami. Za pomocą powyższych poleceń suma kontrolna pliku obrazu jest teraz zgodna z sumą kontrolną dysku SSD. Innymi słowy, ten dysk SSD nie jest zły.