Можно ли отключить тайм-аут жесткого диска в Linux (попытка прерывания задачи)

К сожалению, когда жесткий диск (как правило, виртуальный диск) работает медленно, Linux прерывает запросы на этот диск после таймаута, что может привести к повреждению данных.

В прошлый раз, когда это случилось со мной, у меня было 2 vms (Linux и FreeBSD) на хранилище, которые имели проблемы с подключением и были заморожены более часа. Само хранилище в порядке, ошибок нет, и после установления соединения vms (который, очевидно, также был заморожен), казалось, снова работал.

Тем не менее, Linux vm решил отказаться от запросов, что делает эту систему непригодной (ls на большинстве каталогов застрял, так же, как и без опций, и многие другие вещи больше не работали); необходима перезагрузка. Это ошибки (dmesg):

... [86707.916728] Write(10): 2a 00 02 4c 9e 38 00 03 c0 00 [86707.916732] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff880036865500) [86707.916734] mptscsih: ioc0: attempting task abort! (sc=ffff880036866100) [86707.916735] sd 2:0:0:0: [sda] CDB: [86707.916736] Write(10): 2a 00 02 4c a1 f8 00 03 c0 00 [86707.916739] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff880036866100) [86707.916741] mptscsih: ioc0: attempting task abort! (sc=ffff880036865c80) [86707.916742] sd 2:0:0:0: [sda] CDB: [86707.916743] Write(10): 2a 00 02 4c a5 b8 00 03 c0 00 [86707.916746] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff880036865c80) [86707.916748] mptscsih: ioc0: attempting task abort! (sc=ffff880036864300) [86707.916749] sd 2:0:0:0: [sda] CDB: [86707.916750] Write(10): 2a 00 02 4c a9 78 00 02 b0 00 [86707.916753] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff880036864300) 

Интересно, что FreeBSD vm не имеет ошибок и работает нормально. По-видимому, только FreeBSD работал так, как ожидалось, не прерывая ничего (хотя я думаю, что видел аналогичные сообщения ядра в системах FreeBSD).

Я не знаю, почему ядро ​​убивает ожидающие запросы на запись после таймаута. Вероятно, это имеет смысл в некоторых случаях, но это, конечно, не в моем случае – на самом деле это лишний риск (без этого таймаута Linux vm продолжил бы нормально после восстановления соединения, все бы снова работало).

Как отключить тайм-аут ядра Linux (vm) для замороженных жестких дисков?


Редактировать:

Linux vm имеет только 1 жесткий диск (/ dev / sda), который должен выглядеть как обычный (SCSI-тип) физический диск.
lspci перечисляет этот контроллер: «Контроллер хранения SCSI [0100]: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI [1000: 0030] (rev 01)».

Вот еще один пример (другой vm, тот же хост, также Linux) (в этом случае хранилище не исчезло, но хост находился под большой нагрузкой):

 [1179039.664031] ata2: lost interrupt (Status 0x18) [1179039.727188] ata2: drained 8 bytes to clear DRQ [1179039.727272] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [1179039.740720] sr 1:0:0:0: CDB: [1179039.740759] Get event status notification: 4a 01 00 00 10 00 00 00 08 00 [1179039.740768] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio 16392 in res 40/00:02:00:08:00/00:00:00:00:00/a0 Emask 0x4 (timeout) [1179039.740770] ata2.00: status: { DRDY } [1179039.748067] ata2: soft resetting link [1179039.937757] ata2.00: configured for UDMA/33 [1179039.943435] ata2: EH complete 

Редактировать:

И вот как выглядят ошибки тайм-аута в системе ядра Debian / kBSD (FreeBSD) (тот же хост, такая же ситуация, иная vm):

 mpt0: request 0xffffff80007305d0:62955 timed out for ccb 0xfffffe000a3bb800 (req->ccb 0xfffffe000a3bb800) mpt0: request 0xffffff800072fa90:62956 timed out for ccb 0xfffffe000a3d1000 (req->ccb 0xfffffe000a3d1000) mpt0: request 0xffffff8000726070:62962 timed out for ccb 0xfffffe000a428000 (req->ccb 0xfffffe000a428000) mpt0: attempting to abort req 0xffffff80007305d0:62955 function 0 mpt0: completing timedout/aborted req 0xffffff8000726070:62962 mpt0: completing timedout/aborted req 0xffffff80007305d0:62955 mpt0: completing timedout/aborted req 0xffffff800072fa90:62956 mpt0: abort of req 0xffffff80007305d0:0 completed mpt0: request 0xffffff8000726190:64136 timed out for ccb 0xfffffe000a3d1800 (req->ccb 0xfffffe000a3d1800) mpt0: attempting to abort req 0xffffff8000726190:64136 function 0 mpt0: completing timedout/aborted req 0xffffff8000726190:64136 mpt0: abort of req 0xffffff8000726190:0 completed mpt0: request 0xffffff8000721990:50970 timed out for ccb 0xfffffe00024bf800 (req->ccb 0xfffffe00024bf800) mpt0: attempting to abort req 0xffffff8000721990:50970 function 0 mpt0: completing timedout/aborted req 0xffffff8000721990:50970 mpt0: abort of req 0xffffff8000721990:0 completed mpt0: request 0xffffff80007279c0:61393 timed out for ccb 0xfffffe000a3cf000 (req->ccb 0xfffffe000a3cf000) mpt0: request 0xffffff8000732550:61395 timed out for ccb 0xfffffe000a428000 (req->ccb 0xfffffe000a428000) mpt0: attempting to abort req 0xffffff80007279c0:61393 function 0 mpt0: completing timedout/aborted req 0xffffff80007279c0:61393 mpt0: completing timedout/aborted req 0xffffff8000732550:61395 mpt0: abort of req 0xffffff80007279c0:0 completed 

One Solution collect form web for “Можно ли отключить тайм-аут жесткого диска в Linux (попытка прерывания задачи)”

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

Кроме того, некоторые из комментариев выражают путаницу в отношении того, что hdd я настроил в vm, поэтому я добавил эту информацию к вопросу. И у меня есть несколько Linux vms, работающих одновременно, поэтому ошибки не появляются только в одном vm.

Настройка таймаута (например, в /etc/rc.local ):

Linux:

 TIMEOUT=86400 for f in /sys/block/sd?/device/timeout; do echo $TIMEOUT >"$f" done 

Если этот шаблон ( sd? ) Не соответствует вашему оборудованию, найдите таймауты и проверьте их вручную:

 find /sys/ -name timeout 

Debian / kBSD (GNU / kFreeBSD 9.0-2-amd64):

 sysctl kern.cam.da.default_timeout=86400 

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

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

  • Почему oot говорит «эй» в унии -o?
  • сравнение времени, заданного пользователем для времени файла журнала
  • Тайм-аут не возникает при чтении из fifo с использованием `read`
  • Увеличение времени на завершение запросов
  • Увеличьте SSH ConnectTimeout более 60 секунд
  • Expect script: Как обрабатывать два процесса?
  • Как система X86 Linux поддерживает системное время, когда нет NTP и т. Д.?
  • Проблемы с конфигурацией TFTP
  • Найдите, завершится ли процесс за определенный промежуток времени
  • таймаут без процесса убийства в bash
  • IPTables, удаляющий поток пакетов UDP
  • Interesting Posts

    Отсутствует меню на хостинге Mint с использованием RDP, если не войти в систему на консоли хоста

    Как переименовать несколько файлов, заменив строку в имени файла?

    Как полностью синхронизировать локальный репозиторий с помощью Mercurial (bitbucket)

    «Завершение работы компьютера при завершении» во время этапа кодирования Avidemux?

    Ошибка HTTP-запроса после прослушивания на нескольких портах или после включения модуля SSL на моей плате Linux

    Как запустить программу внутри контейнера Docker?

    Расширение путей в переменных Bash в выражения sed

    Установка средств разработки в RHEL 6

    Использование SUDO для выполнения общей команды внутри не доступного каталога

    Использовать X SSH-ключ при входе в Y удаленному пользователю?

    Rhythmbox не может найти музыку на моем Android-устройстве

    Виртуализация для переключения систем без перезагрузки

    Проверьте в bash, если make сделал что-то

    Создайте дублируемую запись, основанную на условии

    Каталог синхронизации emacs shell

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