LINUX.ORG.RU
решено ФорумAdmin

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

 , ,


0

3

Всем привет,

Внезапно я озадачился такой проблемой. Вот допустим есть у меня система критическая в плане сохранения данных, к примеру сервер базы данных. На ней стоят диски, допустим HDD, хотя возможно и SSD, сути это не меняет. И предположим, диски начинают умирать потихоньку, но ведь сразу диск не умирает, наверняка сначала начнут появляться ошибки чтения в dmesg (который никто никогда не смотрит, пока все не сломается).

Отсюда два вопроса:

  1. Есть ли какой то нативный инструмент контроля и репортинга ошибок записи/чтения на диск? S.M.A.R.T. не предлагайте, потому что в него, во первых, тоже никто никогда не смотрит, а во вторых он не всегда помогает, насколько я понимаю.

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

Заранее благодарю.


Ответ на: комментарий от legolegs
  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.»

  1. Про RAID не понял, но это больше похоже на механизм защиты от отказов.
alex07 ()
Последнее исправление: alex07 (всего исправлений: 2)
Ответ на: комментарий от alex07

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

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

r0ck3r ★★★★★ ()
Последнее исправление: r0ck3r (всего исправлений: 1)
Ответ на: комментарий от r0ck3r

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

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

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

alex07 ()
Последнее исправление: alex07 (всего исправлений: 1)
Ответ на: комментарий от alex07

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

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

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

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

r0ck3r ★★★★★ ()
Ответ на: комментарий от Harald

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

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

r0ck3r ★★★★★ ()

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

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

legolegs ★★★★★ ()
Ответ на: комментарий от r0ck3r

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

legolegs ★★★★★ ()
Ответ на: комментарий от r0ck3r

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

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

Harald ★★★★★ ()

Вот кстати говоря, есть у меня диск на 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.

alex07 ()
Последнее исправление: alex07 (всего исправлений: 1)

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

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

amd_amd ★★★★ ()
Ответ на: комментарий от legolegs

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

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

alex07 ()
Последнее исправление: alex07 (всего исправлений: 1)
Ответ на: комментарий от alex07

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

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

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

Нет.


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

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

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

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от alex07

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

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

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

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

greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 1)
Ответ на: комментарий от amd_amd

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

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

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

# smartctl -x /dev/sda
greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 1)
Ответ на: комментарий от anc

речь про

вот что сообщает 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.
долбит с мая месяца, а arch молчит - хотя на нем тот же самый smartmomtoos установлен...

amd_amd ★★★★ ()
Ответ на: комментарий от anc

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

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

alex07 ()
Ответ на: комментарий от legolegs

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

alex07 ()
Ответ на: комментарий от amd_amd

Offline uncorrectable sectors

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

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

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

anc ★★★★★ ()
Ответ на: комментарий от alex07

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

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

legolegs ★★★★★ ()
Ответ на: комментарий от alex07

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

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

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)

Вот кстати есть у меня сервер для билдов в Хецнере, на обоих драйвах много реалока (но это сигейт), плюс значения 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

alex07 ()
Ответ на: комментарий от alex07

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

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 2)
Ответ на: комментарий от anc

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

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

alex07 ()

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

dm-integrity

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

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

No ()