Я все еще вижу, что люди рекомендуют использовать sync; sync; sync; sleep 30; halt заклинания при разговоре о выключении или перезагрузке Linux.
Я использую Linux с момента его создания, и хотя это была рекомендованная процедура в BSD 4.2 / 4.3 и SunOS 4 дня, я не могу вспомнить, что мне приходилось делать это, по крайней мере, последние десять лет, в течение которых я, вероятно, прошел через выключение / перезагрузку Linux, возможно, тысячи раз.
Я подозреваю, что это анахронизм с тех времен, когда ядро не могло размонтировать и синхронизировать корневую файловую систему и другие критические файловые системы, необходимые даже в однопользовательском режиме (например, / tmp), и поэтому необходимо было явно указать ему очистить как можно больше данных на диск.
В наши дни, пока не удалось найти соответствующий код в исходниках ядра (копаясь в http://lxr.linux.no и google), я подозреваю, что ядро достаточно умен, чтобы чисто размонтировать даже корневую файловую систему, а файловая система достаточно умен, чтобы эффективно выполнять синхронизацию (2) перед размонтированием во время обычного shutdown/reboot/poweorff.
В "sync; sync; sync" требуется только в крайних случаях, когда файловая система не размонтируется чисто (например, сбой физического диска) или система находится в состоянии, при котором только принудительная прямая перезагрузка (8) выведет ее из состояния зависания (например, нагрузка слишком высока чтобы он мог запланировать команду выключения).
Я также никогда не делаю sync перед размонтированием съемных устройств, и никогда не столкнуться с проблемой.
Другой пример - Xen позволяет DomU отправлять shutdown из Dom0, это считается «чистым завершением работы» без необходимости входа в систему и ввода волшебного sync; sync; sync первый.
Прав ли я, или мне повезло с несколькими тысячами отключений системы?
Причина, по которой люди бегут sync; sync перед halt потому что halt команда не завершала работу системы на старых Linux. Правильный способ сделать это в системах SYSVr4 - это всегда указывать init, что нужно перейти на другой уровень выполнения.
BSD и SunOS 4 не являются операционными системами SYSVr4, поэтому они отличаются. Solaris (SunOS 5) - это SYSVr4, и Linux выбирает части стандарта SYSVr4, которые он хочет использовать.
Использование halt на самом деле довольно плохой способ сделать это в большинстве UNIX (Linux является одним из исключений), поскольку он фактически не запускает сценарии инициализации для выполнения таких вещей, как остановка процессов и размонтирование дисков - он просто останавливает процессор.
Если вы можете гарантировать, что вы никогда когда-либо, когда-либо использовали любую систему UNIX, кроме Linux, тогда вы можете продолжать использовать halt - если есть вероятность, что вы собираетесь использовать другие UNIX, я бы рекомендовал выработать привычку использовать init _runlevel_ или shutdown.
В shutdown команда фактически сообщает init процесс для изменения уровня выполнения уровень бега - при этом init затем переходит к запуску каждого из сценариев K * init и сценариев S * init, связанных с этим уровнем запуска. Один из сценариев на уровне выполнения 0 выполняет размонтирование файловых систем.
В Linux halt команда просто вызывает shutdown команда, если уровень выполнения уже не равен 0 (завершение работы) или 6 (перезагрузка) тем не мение; так что никаких потерь нет.
Акт размонтирования файловой системы с использованием umount синхронизирует данные с диском перед его размонтированием.
Если вы бегали sync; sync; halt в Linux все будет в порядке с состоянием файловой системы, потому что разработчики позаботились о том, чтобы halt делает право вещь; однако правильнее было бы использовать: shutdown now
Использование нескольких sync Звонки заключались в том, чтобы дать ОС и дискам время очистить очереди записи. "sync; sync; sync" не считался таким полезным; один сделал "sync<cr> sync<cr> sync<cr" и задержка, пока ваш ASR-33 выполнял возврат каретки / новую строку, обеспечила достаточную задержку. Остановка всегда вызывала синхронизацию; вопрос был в том, хватит ли времени, чтобы очистить очереди до отключения электроэнергии.
Оригинальный плакат sync; sleep 30 больше соответствует тому, что было задумано.
Я могу только поговорите, почему вы выпустите sync многократно. Команда планирует сброс на диск, но возвращается до завершения фактического сброса. Любые последующие sync команда будет блокироваться до тех пор, пока не будет выполнена какая-либо незавершенная очистка, прежде чем запланировать еще одну очистку и выйти. Следовательно, sync; sync обеспечивает синхронный смыв. Больше 2-х раз делать не нужно, ни приносить sleep в смесь.
Те из вас, кто говорит нам всем, что «синхронизация; синхронизация; синхронизация» не имеет цели, раскрывают ваш возраст.
В старые добрые времена, до того, как Unix была чем-то для подростков, нам приходилось использовать TAPE для потоковой передачи / резервного копирования. Часто мы монтировали файловую систему на магнитной ленте для потоковой передачи резервных копий и так далее. Эта одна длинная тонкая полоса магнитной пластиковой ленты была всем, что было у некоторых из нас, чтобы хранить наши файлы ...
Команда 'sync; sync; sync' была способом, с помощью которого этим старым ленточным машинам можно было приказать полностью перемотать себя до конца (перед выключением) - у них была встроенная прошивка, которая получала команду синхронизации (как и все хорошие файловые системы do), и если бы за ним почти сразу последовали еще две команды буфера синхронизации, сам ленточный накопитель интерпретировал бы это как «перемотать ленту и размонтировать ее». Не было никакого способа указать ленточному накопителю перемотать, кроме этого метода, и он вроде как застрял ... Эта привычка затем перешла в мир, когда жесткие диски стали более доступными - мы, твердые старые операторы, не просто перераспределяем ( ) наша мышечная память вы знаете! Я считаю, что он получил статус фольклора вскоре после того, как ленты стали менее распространенными, а жесткие диски стали более доступными, но он все еще находит применение для тех из нас, у кого есть ленточные накопители.