Как уменьшить время, процессы ожидали бы (заблокированные) чтения с диска (только для обнаружения ошибки)?
Я предоставлю фрагмент кода с помощью tmux, который может дать вам два разных окна, которые вы можете использовать для хвоста обоих файлов одновременно:
tmux new-window -a -n Tail
tmux new-session -d -s Tail -n SSH0 -d
tmux selectp -t Tail
#This is tmux interactions with the user (colors of the tabs used, hot keys, etc.)
tmux bind-key -n M-Left previous-window -t WinSplit
tmux bind-key -n M-Right next-window -t WinSplit
tmux set-window-option -g monitor-activity on
tmux set -g visual-activity on
tmux set-window-option -g window-status-current-bg blue
tmux set-window-option -g window-status-fg red
tmux set -g pane-border-fg yellow
tmux set -g pane-active-border-bg red
tmux set -g message-fg yellow
tmux set -g message-bg red
tmux set -g message-attr bright
tmux set -g status-left "#[fg=red]#S"
#Names two seperate windows
tmux new-window -n tail1 -t Tail
tmux new-window -n tail2 -t Tail
#Now this will allow you to automatically run tail when this tmux script is run
tmux send-keys -t Tail:0 'tail -f file1.log' C-m
tmux send-keys -t Tail:1 'tail -f file2.log' C-m
UPDATE: Использование screen также может прикрепить/открепить несколько сеансов, так что вы можете запустить tail также несколько раз. Могу предложить следующее:
экран -s Tail_Server1. log
Далее вы захотите удерживать CTRL+A+D, чтобы отсоединить, не убивая сеансы, а затем:
screen -s Tail_Server2.log
Оба запускают два отдельных экрана -, я бы обратился к экрану -help, чтобы вы могли настроить его так, как вы хотите, чтобы оба экрана работали на вашем -терминале .
Можно ли настроить диск (ATA) так, чтобы неудачное чтение не заняло слишком много времени, чтобы его можно было сбросить, а процесс чтения и диск не был заблокирован, и можно было бы попытаться выполнить следующее чтение?
Нет.
Мое понимание этого заключается в том, что это логическая проблема, возникающая в результате выбора конструкции (не уникальной для linux), которая благоприятствует производительности и стабильности работающего аппаратного обеспечения, так как нельзя разумно ожидать, что операционная система будет справляться с бесконечными возможностями, предоставляемыми "возможно, неисправным" аппаратным обеспечением. У нас есть a Q&A по этому поводу .
если вы пытаетесь прочитать столько данных, сколько можно прочитать с диска с плохими секторами
Если это плохие сектора, то вам повезло; размонтируйте затронутые разделы и (предполагая, что они отформатированы в ext) запустите e2fsck -cy /dev/wevereverever на них. Коммутатор -c запускает badblocks и добавляет отдельные адреса в "список плохих блоков" раздела; при последующем монтировании система никогда не будет пытаться получить доступ к ним. Это может означать, что вы потеряли некоторые данные; биты их можно найти в каталоге /lost+found. Переключатель -y избавляет вас от необходимости вручную говорить "Да, исправьте это" в вопросах fsck, которых может быть очень много.
Однако, если это неплохие блоки (например, неисправный контроллер), вам не повезло. Неудачные блоки, вот почему ведение регулярного резервного копирования жизненно важных данных так важно. Я не уверен, что запуск e2fsck -cy на диске со сломанным контроллером может сделать ситуацию хуже, но OTOH, если вы все равно не можете получить то, что вам нужно, вам нечего терять.
В большинстве систем Unix не реализовано асинхронное чтение локальных дисков; попытка вызова приводит к синхронному чтению. В частности, в Linux непрерывный сон локальных дисков (что раздражает на поцарапанных компакт-дисках).
Если на вашей платформе происходит прерывание ввода-вывода локального диска, вы можете использовать alarm (); читать(); чтобы установить максимальное время ожидания.