Почему этот SSD возвращает противоречивые данные, почему файл образа резервной копии не совпадает с контрольной суммой?

Question

Это про SSD в ноутбуке. Похоже, что SSD уже выходит из строя, возможно, даже портит данные. Кажется, он возвращает разные данные каждый раз, когда к ним обращаются, когда они не используются (подробности см. Ниже). Какие инструменты могут быть использованы для подтверждения этого подозрения?

Когда жесткий диск медленно начинает умирать, в выводе SMART обычно есть четкая индикация, графический инструмент, такой как gsmartcontrol определенное значение красным цветом, и такая служба, как smartd может уже выдать предупреждение. В этот момент у пользователя может остаться время для создания резервной копии, прежде чем диск начнет повреждать данные. Конечно, если диск уже начал повреждать данные, некоторые файлы в этой резервной копии могут быть повреждены.

Похоже, в выводе SMART нет четких предупреждений для этого SSD, ошибки ядра не были зарегистрированы в dmesg и т.д. (С другой стороны, ecryptfs регистрирует ошибки). Другими словами, только случайно было обнаружено, что этот SSD уже может быть настолько плохим, что портит данные, даже когда он не используется.
Сделав резервную копию (1:1 dd-образ) этого SSD (sda), я обнаружил, что контрольная сумма файла образа не совпадает с контрольной суммой SSD. Конечно, это было в действующей системе, поэтому SSD не был смонтирован, что означает, что его содержимое не могло измениться в процессе резервного копирования.

Это то, что я сделал, чтобы сделать резервную копию. "BUTTER" - это место, где я смонтировал внешний диск, отформатированный с помощью BTRFS, чтобы я мог узнать об ошибках данных в случае, если резервный диск также неисправен (в отличие от большинства других файловых систем, BTRFS имеет контрольные суммы).

[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

Я создал контрольную сумму MD5 для файла изображения и другой SDD, и они не совпадали. Повторив эту процедуру, я понял, что контрольная сумма MD5 SSD отличается каждый раз.

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

Опять же, SSD никогда не был подключен ни в одной точке во время этого процесса.

# mount | grep -c sda
0

Я запустил SMART тест, который ничего не нашел. Ошибка SMART не регистрируется.
УМНЫЕ атрибуты:

Модель устройства: 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

Что происходит?

Answer 1

Сразу после публикации этого вопроса я обнаружил свою ошибку. Я использовал Fedora XFCE в качестве работающей системы, которая автоматически включала раздел подкачки, который просто находится на рассматриваемом SSD. И, конечно же, в то время как работающая система активно использовала раздел подкачки на SSD, она тем самым меняла содержимое SSD.

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

Это немного неловко сейчас, когда я уже разместил вопрос. Но я оставлю это там, надеясь, что это будет полезно для кого-то еще, кто может сделать ту же ошибку.

Все, что мне нужно было сделать, это отключить раздел подкачки, который ранее автоматически монтировался:

[root@localhost mnt]# swapoff -a

Я хотел бы отметить, что раздел подкачки был смонтирован автоматически при загрузке работающей системы. Я не хотел монтировать этот раздел подкачки. Интересно, что произойдет, если на этом разделе подкачки будет спящий образ.

После отключения ненужного раздела подкачки все заработало как положено. Используя команды, показанные выше, контрольная сумма файла изображения теперь совпадает с контрольной суммой SSD. Другими словами, этот SSD не плохой.