Странные данные SMART у SSD, из-за чего и когда менять диск?

Question

[Yoh]

Здравствуйте.

Есть два компьютера, в которых по два SSD диска Samsung EVO 850 (500 гб) объединенных в программный RAID-1.

Один собран в начале 2015 года, работает всё работает до сих пор, параметр Wear_Leveling_Count на обоих дисках снижается синхронно, сейчас записано 89 тб, значения Wear_Leveling_Count на обоих дисках 29.

Второй собран в середине 2016 года и в работе одного диска есть странность. На оба диска записано по 50 тб (смотрю исходя из параметра Total_LBAs_Written), но на одном диске параметр Wear_Leveling_Count равен 72% (вполне нормальное значение), а на другом диске 41% (что ненормально).

Обратился в поддержку Samsung, там мне дали шаблонный ответ, даже не посмотрев данные SMART, что я отправил (ведь как писал ранее, исходя из данных того же SMART видно, что на диски записан одинаковый объем информации):

Разница значений в параметре зависит от построения RAID-массива. Например, в RAID1 параметр Wear_Leveling_Count может уменьшаться в случаях, когда накопителям нужна пересинхронизация: SSD 2 был неактивен и RAID должен будет перезаписать данные с SSD 1 на SSD 2, после его активации в системе.

Прошивки всех 4 дисков одинаковые, номера моделей совпадают.
RAID-1 используется для повышения надежности (диски выходят не только из-за исчерпания ресурсов, но и непредсказуемом выходе контроллера диска - личный опыт), поэтому, не надо писать, что это не имеет смысла в случае с SSD.

Подскажите, по какой причине может быть такое расхождение в параметрах Wear_Leveling_Count при одинаковом записанном объеме информации? Как определить, когда пора менять проблемный диск? Когда Wear_Leveling_Count будет подходить к 0 или же всё же смотреть по ресурсу записи, которое заявлет производитель (около 150 тб)? Может быть кто-то сталкивался, модели дисков популярные.

[~]# smartctl -A /dev/sda
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.10.0-327.36.3.el7.x86_64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 7637
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 17
177 Wear_Leveling_Count 0x0013 072 072 000 Pre-fail Always - 580
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 067 064 000 Old_age Always - 33
195 Hardware_ECC_Recovered 0x001a 200 200 000 Old_age Always - 0
199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0
235 Unknown_Attribute 0x0012 099 099 000 Old_age Always - 4
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 108741171263

[~]# smartctl -A /dev/sdb
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.10.0-327.36.3.el7.x86_64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 7637
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 17
177 Wear_Leveling_Count 0x0013 041 041 000 Pre-fail Always - 1249
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 070 062 000 Old_age Always - 30
195 Hardware_ECC_Recovered 0x001a 200 200 000 Old_age Always - 0
199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0
235 Unknown_Attribute 0x0012 099 099 000 Old_age Always - 3
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 109374845811

Answer 1

[АртемЪ]

Wear_Leveling_Count не самый надежный параметр, все их считают по разному, и зачастую он то обнуляется, то вообще погоду показывает.
Смотрите на Total_LBAs_Written, судя по нему записано на оба диска по 50тб, разница в записи 300гб.
В принципе такое расхождение может быть вызвано тем что TRIM не доходит до одного из дисков.
Хотя если у вас сервер, то лучше бы не полагаться на трим, а оставить приличный over provisioning.

Как определить, когда пора менять проблемный диск?

Ориентируйтесь по Total_LBAs_Written и отслеживайте нездоровые движения по Reallocated_Sector, Used_Rsvd_Blk_Cnt_Tot, Erase_Fail_Count_Total

Comments

[АртемЪ]

Ну и еще можно посмотреть в плане выравнивания разделов. Хотя если софт не древний маловероятно.

[Yoh]

АртемЪ: все самое свежее. Спасибо за консультацию, буду наблюдать.

Answer 2

[Gavric]

Wear_Leveling_Count у Samsung 850 EVO рассчитывается исходя из того, что производитель считает ячейки TLC 3D V-NAND способными на 2100 циклов перезаписи. Реальные же тесты выносливости (https://3dnews.ru/938764) показывают, что в реальности они переносят в 6-7 раз больше перезаписей, и на 850 EVO даже ёмкостью 250 Гбайт можно записать более 2 Пбайт данных. Так что причин для беспокойства нет никаких.
Расхождение же возможно по миллиону причин. Например, у дисков с завода разный объём резервной области. Это нормально, т.к. часть флеша, установленного в накопителе, всегда битая. И её отключают программным образом. Это прямо влияет на коэффициент усиления записи и вызывает расхождения в циклах перезаписи. Но в любом случае волноваться с Вашими показателями S.M.A.R.T. совершенно не о чем.

Answer 3

[Константин Степанов]

1) Разное качество памяти на дисках. Ячейки на одном диске бьются быстрее и диск считает что он уже достаточно изношен.
2) Глюк прошивки и не обращайте внимания.

Comments

[Yoh]

Надеюсь на второе, подозреваю, когда будет реальный износ диска, то будет снижаться параметр Used_Rsvd_Blk_Cnt_Tot, а если умрет при Wear_Leveling_Count менее 10 и данных записано будет менее 150 тб, то по гарантии сдать можно.