Отлавливание ошибок чтения/записи на диск

1. smartd шлёт письма

2. RAID

1. Насколько я понял smart не всегда достоверно показывает реальное положение дел. Дабы не быть голословным: http://static.googleusercontent.com/media/research.google.com/en//archive/disk_failures.pdf.

А именно:

«…failure prediction models based on SMART parameters alone are likely to be severely limited in their prediction accuracy, given that a large fraction of our failed drives have shown no SMART error signals whatsoever.»

2. Про RAID не понял, но это больше похоже на механизм защиты от отказов.

RAID тебя защитит от порчи данных. Так, если у тебя не прочитался какой-то сектор на диске А, то эти данные считаются с диска Б, а SMART диска А получит отметку о сбойном секторе. Затем smartd уведомит тебя по почте о наличии проблем на диске А

UPDATE: это актуально для зеркального RAID

RAID тебя защитит от порчи данных.

То есть я правильно понимаю что для критических данных единственный выход это RAID1, а все остальное читать через SMART?

Просто ведь ядро оно тоже иногда выкидавает I/O Error, и если это мониторить то лишний раз повод задуматься, учитывая если нет RAID и SMART проглядел ошибку.

То есть я правильно понимаю что для критических данных единственный выход это RAID1, а все остальное читать через SMART?

да, именно так

Просто ведь ядро оно тоже иногда выкидавает I/O Error, и если это мониторить то лишний раз повод задуматься. Учитывая если нет RAID и SMART проглядел ошибку.

ошибки I/O не возникают просто так. Вообще файлы в файловой системе имеют чексуммы, которые сверяются при работе и если они не в порядке, то дело, вероятнее всего, в кривом железе

RAID не защищает от порчи данных, он обеспечивает отказоустойчивость
от порчи данных защищает бекап

ошибки I/O не возникают просто так.

Ок. Понял.

Спасибо.

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

пруфы

Хм, нашел ссылку только про Btrfs. По ходу у других такого нет. https://btrfs.wiki.kernel.org/index.php/FAQ#What_checksum_function_does_Btrfs_use.3F

Тогда встречный вопрос: как вообще SMART узнает, что блок умер?

Возможно ли как то спровоцировать ошибку чтения диска не ломая сам диск при этом. Это нужно для тестинга.

Питание ему дергаешь, вот и ошибка. Сата можно отключать на горячую на большинстве матерей в режиме ACHI.

Диск для каждого 4096 байтного блока хранит там же контрольную сумму и сверяет при каждом чтении. Если она не сходится- это и называется «блок не читается» - он на самом деле читается, только белиберда получается. При этом серверные НЖМД возвращают ошибку, а десктопные пробуют прочитать ещё несколько раз, это выглядит как «комп завис/тормозит».

после неудачного чтения сектора инкрементирует счётчик битых секторов

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

а, вот. Значит я с уровнем ошибся. Я думал контрольная сумма хранится в ФС. Спасибо за разъяснение

понял, спасибо

mdadm тоже шлёт письма.

smartd + mdadm + бекапы.

спровоцировать ошибку чтения диска

https://aur.archlinux.org/packages/libfiu/

Или сделать ФС на nandsim который в ядре и умеет генерировать бедблоки. Но это mtd-устройство.

Вот кстати говоря, есть у меня диск на 1Tb на котором крутится виртуальный виндоус для игр.

После выполнения smartctl -a /dev/sdc вижу следующее:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   111   099   006    Pre-fail  Always       -       32448110
  3 Spin_Up_Time            0x0003   094   094   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   075   075   020    Old_age   Always       -       26382
  5 Reallocated_Sector_Ct   0x0033   095   095   036    Pre-fail  Always       -       220
  7 Seek_Error_Rate         0x000f   082   060   030    Pre-fail  Always       -       193760749
  9 Power_On_Hours          0x0032   025   025   000    Old_age   Always       -       66221
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       699
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   002   002   000    Old_age   Always       -       98
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       8590065667
189 High_Fly_Writes         0x003a   098   098   000    Old_age   Always       -       2
190 Airflow_Temperature_Cel 0x0022   061   047   045    Old_age   Always       -       39 (Min/Max 34/43)
194 Temperature_Celsius     0x0022   039   053   000    Old_age   Always       -       39 (0 9 0 0 0)
195 Hardware_ECC_Recovered  0x001a   030   020   000    Old_age   Always       -       32448110
197 Current_Pending_Sector  0x0012   099   099   000    Old_age   Always       -       44
198 Offline_Uncorrectable   0x0010   099   099   000    Old_age   Offline      -       44
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       67631 (0 52 0)
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       3558263021
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       1371449262

Правильно ли я понимаю что данный диск весьма скоро умрет?

Update: Забавно что значения Raw_Read_Error_Rate и Hardware_ECC_Recovered совпадают. Это видимо и есть те самые исправления с помощью контрольной суммы о которых говорил @Harald.

Есть ли какой то нативный инструмент

у меня на всех машинах по 2 независимых винта - на одном arch, на другом debian... и вот на одной из машин debian повадился при запуске сообщать, что на винте где установлен arch - есть побитые сектора, хотя сам arch молчит и битых секторов не видит... в grub, fstab или еще где либо винты не пересекаются и автоматически друг к другу не монтируются... сообщения появляются в виде писем в каталоге /var/mail ничего специально не настраивал - оно само

Диск сыпется, факт. И на чтении любого из 44 pending блока винда будет виснуть.

И на чтении любого из 44 pending блока винда будет виснуть.

А вот мне еще всегда было интересно, разве не должен софт автоматом переносить данные (какие может) из этих секторов, помечать их как аварийные и никогда больше не пытаться что либо прочитать/записать туда? Пусть и с потерей емкости.

Забавно что значения Raw_Read_Error_Rate и Hardware_ECC_Recovered совпадают.

Если у вас например сигейт то норма, можно не париться.

Это видимо и есть те самые исправления с помощью контрольной суммы о которых говорил @Harald.

Нет.

Правильно ли я понимаю что данный диск весьма скоро умрет?

Ну он как бэ уже умирает :) У вас реалок 220.

Далее, Command_Timeout запредельное значение у вас с кабелями все в порядке?

А вот мне еще всегда было интересно, разве не должен софт автоматом переносить данные (какие может) из этих секторов, помечать их как аварийные и никогда больше не пытаться что либо прочитать/записать туда?

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

Ну видимо у вас на дебе установлен smartd а на арче нет. Ваш КО.

Почти так. В дебе при установке smartmontools smartd автоматом становится активным. В арче, после установки smartmontools, сервис smartd надо ещё запустить.

smartd надо ещё запустить

# systemctl enable smartd
# systemctl start smartd

# systemctl enable --now

И что, всё равно арч не видит?

Смотрите конфиг

всё равно арч не видит?

нет не видит и badblocks ничего не находит

badblocks ничего не находит

И не должен до поры, до времени.

Посмотри smart. Там всякие relocated sectors должны/могут расти.

# smartctl -x /dev/sda

и badblocks ничего не находит

Так у вас уже в бэды полезло, или пока речь про реалок?

речь про

вот что сообщает debian

The following warning/error was logged by the smartd daemon:

Device: /dev/sdb [SAT], 5 Offline uncorrectable sectors

Device info:
SAMSUNG SP0802N, S/N:S00JJ50XA26276, FW:TK200-04, 80.0 GB

For details see host's SYSLOG.

You can also use the smartctl utility for further investigation.
The original message about this issue was sent at Thu May  9 08:09:44 2019>
Another message will be sent in 24 hours if the problem persists.

The original message about this issue was sent at Thu May 9 08:09:44 2019

Как-то надо сбросить ошибку. Он тебя об этих пяти секторах уже почти год долбит, похоже.

Если у вас например сигейт то норма, можно не париться.

А можно подробнее про это? Потому что я вот сейчас все сигейты проверил и на всех эти значения (Raw_Read_Error_Rate) предельно высоки, но всегда идентичны Hardware_ECC_Recovered.

Это свойство сигейта, для него это нормально, забыть и забить.

Это только при записи в сектор происходит. Именно поэтому «форматирование» помогает при проблемах с бедблоками, а fsck/chkdsk - нет.

То есть я правильно понимаю что для критических данных единственный выход это RAID1

И периодический бекап с проверкой.

Я скорее имел в виду что вот если есть диск 1Тб и на нем появились битые блоки, размером, допустим, 100Мб. Было бы круто если бы диск просто стал размером 900Мб, а битую область пометил как не рабочую перманентно.

Offline uncorrectable sectors

Это неведомая хрень, близкая но не совсем к Current_Pending_Sector, может увеличиваться и уменьшаться. Изменяеться при самотестировании харда. Но подробного объяснения этому параметру нет, все зависит производителя. Типа это может быть и плохо и ничего страшного. У меня на одном харде, на котором практически никакой активности (софт роутер), этот параметр прыгал рандомно и весьма долго.

а arch молчит - хотя на нем тот же самый smartmomtoos установлен...

Ещё раз, смотрим настройки.

диск 1Тб

размером, допустим, 100Мб

стал размером 900Мб

Норм такая потеря ёмкости.

https://www.ixbt.com/storage/hdd-smart-testing.shtml#n1

Если проблемная область в середине диска, то после её вырезания как будем остальные блоки нумеровать? И что про это подумает файловая система?

Ну и не говоря уже о том, что такая огромная сбойная область означает, что в диск заполз таракан и продолжает размазываться об блины.

Я скорее имел в виду что вот если есть диск 1Тб и на нем появились битые блоки, размером, допустим, 100Мб. Было бы круто если бы диск просто стал размером 900Мб, а битую область пометил как не рабочую перманентно.

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

как будем остальные блоки нумеровать?

ну вот да, я подозревал что это технически сложно(не)реализуемо.

ну вот да, я подозревал что это технически сложно(не)реализуемо.

Читайте мой пост выше. реалок для этого и придумали.

Вот кстати есть у меня сервер для билдов в Хецнере, на обоих драйвах много реалока (но это сигейт), плюс значения 197 Current_Pending_Sector и 198 Offline_Uncorrectable отличные от нуля.

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

Dear Client.

Reallocating sectors is normal work for a drive so this is >nothing to be worried about. Please monitor the values «197 Current_Pending_Sector» and «198 >Offline_Uncorrectable». They should go back to 0 soon. If they do >not, please contact us again so we can replace the drive.

Kind regards

Они вам написали только про 197 и 198, но не про 5. Реалок это уже безносая с косой высотой 3.5" :) (старая шутка).
5 не уменьшается в отличии от софтбэдов. Даже единичка в этом параметре «уже всё плохо».

Они вам написали только про 197 и 198, но не про 5

Про 5 я им сам написал. А они отвечают мол, ничего страшного, реалок это норм. процедура для жесткого диска. Видимо менять не хотят.

Хм. Я бы по голове постучал им.

Хм. Я бы по голове постучал им.

Ну учитывая что там RAID1 и показатель 5 на другом диске в норме, то я поругаюсь с ними конечно, но без паники.

Есть ли какой то нативный инструмент контроля и репортинга ошибок записи/чтения на диск?

dm-integrity

Возможно ли как то спровоцировать ошибку чтения диска не ломая сам диск при этом. Это нужно для тестинга.

Проверка работы dm-integrity при помощи записи случайных данных на диск - https://gist.github.com/MawKKe/caa2bbf7edcc072129d73b61ae7815fb#file-cryptsetup-with-luks2-and-integrity-demo-sh-L113