Ловушка «READ FPDMA QUEUED»

Недавно я столкнулся с сообщением ядра:

ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0 ata3.00: irq_stat 0x40000008 ata3.00: failed command: READ FPDMA QUEUED ata3.00: cmd 60/08:00:98:b2:78/00:00:13:00:00/40 tag 0 ncq 4096 in res 41/40:08:9a:b2:78/00:00:13:00:00/00 Emask 0x409 (media error) <F> ata3.00: status: { DRDY ERR } ata3.00: error: { UNC } ata3.00: SB600 AHCI: limiting to 255 sectors per cmd ata3.00: SB600 AHCI: limiting to 255 sectors per cmd ata3.00: configured for UDMA/133 sd 2:0:0:0: [sda] Unhandled sense code sd 2:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE sd 2:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor] Descriptor sense data with sense descriptors (in hex): 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 13 78 b2 9a sd 2:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed sd 2:0:0:0: [sda] CDB: Read(10): 28 00 13 78 b2 98 00 00 08 00 end_request: I/O error, dev sda, sector 326677146 ata3: EH complete 

Мне удалось исправить ошибку и написал подробное описание запутанного процесса, который я использовал для восстановления диска. Потом стало слишком лениво, чтобы опубликовать его (думаю, я буду в эти выходные).

Теперь я хотел бы создать несколько программ для автоматизации процесса. Для этого мне нужно «захватить ошибку ядра».

Под ловушкой я имею в виду: 1) Завершить системный вызов, вызывающий ошибку. Я замечаю, что часто такие ошибки, как это, заставят hd зависать, то есть игнорировать запросы от других вызовов системных команд, пока этот процесс не пройдет. Часто приводит к тому, что другие вызовы возвращают ошибки. С помощью диагностической программы это приведет к тому, что неправильное действие будет идентифицировано как преступник.

2) Отправьте сигнал какого-либо сигнала вызывающему процессу, чтобы он знал, что он является виновником.

Предложения?

  • Разделяйте неизменные данные из центрального хранилища в сети
  • Только для чтения файловой системы, которая позволяет также временно записывать в другое место назначения
  • Синхронизация фактической версии хранилища Mercurial для нескольких рабочих мест
  • Сапоги Fedora 24 для чтения
  • Вопрос о выпуске HQ QLogic
  • Как проверить, поддерживает ли контроллер sata hotswap?
  • ограничить приватный репозиторий apt с помощью rssh - почему apt-get try / bin / sh?
  • Один лайнер для удаления репо с добавлением zypper addrepo на OpenSuse?
  • 2 Solutions collect form web for “Ловушка «READ FPDMA QUEUED»”

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

    Например, отправьте запись, а затем выйдите. Запись будет находиться в буферах ядра, пока ядро ​​не выполнит обратную запись. В этот момент может возникнуть ошибка ввода-вывода.

    Когда программа все еще существует, об этой ошибке уже будет сказано. Например, read будет устанавливать errno в EIO . (Эта ошибка может также возвращаться из write , fsync , fdatasync или даже close .)

    Причина, по которой она вечна, не имеет ничего общего с ядром, это всего лишь диск. Привод тратит некоторое время на повторную попытку чтения, чтобы узнать, может ли он понять поврежденный сектор. Если вы этого не хотите (например, потому, что вы используете RAID, и просто перепланируете сектор на зеркало диска), вы можете попробовать изменить настройки контроля ошибок SCT с помощью smartctl. Остерегайтесь того, что многие не-корпоративные диски не поддерживают это.

    За исключением случая с RAID (или аналогичным), нет возможности автоматически его исправить. Данные были потеряны. Ядро не может это исправить.

    Если вы используете Linux-RAID-массив RAID (mdraid), даже с половинным последним ядром, mdraid автоматически исправит его, прочитав сектор с ошибками из зеркала, а затем вернет правильный сектор обратно на диск с ошибкой чтения.

    Если вы получаете это вместо записи вместо записи , замените диск.

    (BTW: READ FPDMA QUEUED не является ошибкой. Его просто команда (S) ATA не удалась. «Средняя ошибка» – это ошибка.)

    У меня такая же проблема: «неудачная команда: READ FPDMA QUEUED». Я решил ее, заменив кабель питания на жестком диске и кабель для передачи данных, и проблема исчезла.

    Linux и Unix - лучшая ОС в мире.