Что произошло бы, если бы жесткий диск перестал работать, в то время как ядро Linux работало?

Это - просто немного исторического хлама. Давным-давно, игры были дополнительной частью системы и могли бы быть установлены различными людьми, таким образом, они жили в /usr/games вместо /usr/bin. Данные, такие как рекорды прибыли для проживания в /var/games. Поскольку время прошло, люди по-разному вставляют переменные игровые данные /var/lib/games/NAME или /var/games/NAME и статические игровые данные в /usr/lib/NAME или /usr/games/lib/NAME или /usr/games/NAME или /usr/lib/games/NAME (и то же с share вместо lib для архитектурно-независимых данных). В наше время нет никакого неопровержимого довода для разделения игр, это - просто вопрос традиции.

7
02.09.2017, 05:20
3 ответа

Отказы оборудования всегда рискуют катастрофического отказа Ядра, так как те пути выполнения кода обычно имели намного меньше тестирования, но обычно, неудавшийся жесткий диск не должен разрушать Ядро. То, что точно происходит, зависит от природы отказа. Возможно, только определенные секторы являются теперь нечитабельными частями рендеринга / домашний нечитабельный раздел, система все еще будет выполнима, чтобы системный администратор проанализировал проблему. Если корневая файловая система становится неприменимой, система в значительной степени мертва независимо от катастрофического отказа Ядра, поскольку даже простая оболочка не будет доступна. Если раздел подкачки станет недоступным, то программы, которые используют подкачку, сегментируют отказ, когда это прибудет, время для чтения в любом выгрузило данные. Если жесткий диск, который отказал, является просто дополнительным устройством хранения данных, он может иметь мало влияния помимо некоторых файловых систем, становящихся нечитабельным.

Это может также зависеть от того, какие ошибки жесткий диск бросает. Я видел, что диск эффективно исчезает и помимо исчезновения файловых систем, все работало хорошо. Я также видел жесткий диск, постоянно подвешивающий систему и бросающий ошибки после долгого тайм-аута, заставляющего целую производительность системы ухудшиться. При использовании слоя как MD, работающий RAID1/4/5, серьезная ошибка будет обычно просто заставлять Ядро отмечать диск, как отказавший, и это проигнорирует его полагающийся на остальные диски для поддерживания системы в рабочем состоянии.

13
27.01.2020, 20:15
  • 1
    так же, как другое примечание... недостающие файлы будет не обязательно мешать существующим приложениям работать. Таким образом, если Ваша корневая файловая система исчезнет, и у Вас есть открытая оболочка, то... сама оболочка будет доступна, хотя coreutils не будет. –  xenoterracide 13.04.2011, 11:38
  • 2
    На самом деле даже запущенное приложение может отказать. Когда исполняемый файл загружается, его изображение просто отображается в виртуальную память. Если выполнение программы переходит для кодирования на странице, которая еще не была разбита на страницы в, удар. –  JeremyP 13.04.2011, 15:39
  • 3
    , я помню 'Страшную историю Unix', где кто-то вошел в систему, поскольку корень выполнил комнату-rf / и удалил почти все на диске. Странные вещи произошли, но они смогли придумать восстановление на этом тихом выполнении, но системе, которой наносят вред. Это - интересное чтение: macnugget.org/stuff/unix-horror-story.txt –  Andrew Lambert 13.04.2011, 20:17

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

Я не мог загрузить новые программы, программы, которые были загружены продолжавшие выполнять, но с ошибками, если они попытались записать в диск. Все еще имел bash запросите я вошел, сеть продолжала функционировать. Было удивительно не столь катастрофическим, как я буду ожидать.

Я думаю, что это - "чистый" отказ, хотя, потому что независимо от того, что драйвер был ответственен за чтение/запись в PERC, казалось, отклонял все сразу с ошибкой (забудьте точный, но это была ошибка смысла SCSI). Это было бы намного хуже, если бы диск не отвечал, отвечая медленно, или записи, казалось, работали хорошо, но действительно не были.

3
27.01.2020, 20:15

У меня на самом деле был сбой диска в рабочей системе, № X все же. Никакие логины не были возможны, потому что getty не был доступен. Я пытался окружить из запущенного приложения, но никакая оболочка не была доступна, и приложение было затем неприменимо. Это - когда сообщение Aiieeee привлекло мое внимание и рассказало историю.

0
27.01.2020, 20:15

Теги

Похожие вопросы