Изменить: Краткое содержание (версия --verbose ниже): мне нужно, чтобы машина быстро отключилась при отключении электроэнергии из-за короткого срока службы батареи. Есть ли причина, по которой мне не следует использовать 'umount -f' (встроенный в сценарий отказа питания) на рабочем диске, ввод-вывод которого задерживает завершение работы, и чьи данные меня не волнуют, если задания мертвы тем не мение?
вопрос от новичка сисадмина (давний пользователь * nix).
Я недавно установил вычислительный сервер CentOS, и apcupsd разговаривал с моим ИБП, так что он плавно отключается, как только мы теряем питание (это все, на что у меня есть деньги). Местная энергетическая компания успела проверить это, прежде чем у меня хватило смелости вытащить вилку (блин!). Это дало мне несколько очень напряженных моментов, когда потребовалось около 10 минут, чтобы размонтировать файловые системы, доведя батарею до 12% перед окончательным отключением.
Это заняло так много времени, потому что я завалил машину тяжелыми заданиями ввода-вывода, готовясь к более простому тесту: подать команду «остановить», чтобы посмотреть, сколько времени займет завершение работы. Все тяжелые операции ввода-вывода занимают пустое место на выделенных дисках в RAID0. Если работа умирает, мне все равно, что находится на этих дисках. Я даже могу позволить себе переделать файловую систему после такого сбоя. Было бы неприятно, если бы какой-либо из более легких дисков (домашних каталогов) был поврежден, если батарея разрядится до завершения выключения.
Тем не менее, в apcupsd есть место, где системный администратор может вставить сценарий bash, который запускается при выполнении определенных условий. Если это состояние - сбой питания, и я действительно не забочусь о том, чтобы повредить царапинные данные, чтобы получить быстрое завершение работы, является ли 'umount -f' моим другом?
Я что-то не рассматриваю? Обязательно ли мне нужно будет переделывать файловую систему после этого или просто удалить наиболее поврежденные файлы на диске?
Предполагая, что вы действительно нашли основную причину своего длительного отключения и отсутствие заботы о целостности данных в этой конкретной файловой системе, вам обязательно нужно попробовать umount -f.
Однако я думаю, что это вряд ли решит вашу проблему: umount -f будет работать с неотвечающими серверами NFS и открытыми дескрипторами файлов, но он все равно будет записывать буферизованные данные в файловую систему. Если у вас уже есть так много данных, ваш скрипт umount все равно займет много времени.
Было бы неплохо также убить (или убить -9) ваши задания, выполняющие тяжелые операции ввода-вывода в вашей рабочей файловой системе, чтобы убедиться, что в очереди нет дополнительных операций ввода-вывода.