Есть ли правда в философии, которую вы должны синхронизировать? синхронизации; синхронизации; синхронизация?

Когда я впервые познакомился с Linux, работая в Cisco Systems в 2000 году, меня научили достоинствам syncкоманды, используемой для сброса буферов на диск, чтобы предотвратить повреждение файловой системы / потерю данных. Мне сказали не только коллеги из колледжа, но и друзья из колледжа, что они всегда проводят sync«несколько» или «кучку» раз, то есть, может быть, 5–10 раз вместо одного раза.

С тех пор я продолжил эту привычку, но есть ли в этом смысл? Кто-нибудь еще слышал это? И самое главное, может ли кто-нибудь предоставить хорошее обоснование / эмпирическое доказательство за / против идеи, что вам нужно запускать syncнесколько раз, чтобы она была эффективной?

Я слышал это (извините, я забыл, где), как ввод syncкоманды три раза (как в:, S Y N C Returnждать приглашения, повторить, повторить). Я также читал, что источником была особая система, где диску потребовалось бы несколько секунд, чтобы завершить очистку своих буферов, даже после того, как он сказал операционной системе, что все в порядке. Дважды введя команду, диск получил достаточно времени для установки. Похоже, что за sync; sync; syncпрошедшие годы цель была забыта, а совет был сокращен, так как это не имело бы желаемого эффекта (поскольку диск сообщал «все чисто», вторая и третья синхронизация завершались бы мгновенно, и подсказка вернулся бы слишком рано).

Я никогда не слышал о системе, в которой несколько syncопераций имеют какое-либо применение, и я очень скептически отношусь к любой существующей. Я считаю это городской легендой. С другой стороны, я считаю весьма вероятным, что будут системы, в которых вы должны подождать пару секунд после синхронизации и перед выключением.

Поиск в Google приводит к нескольким независимым параллельным анализам, например, «Легенда синхронизации» . См. Также Требуется ли выполнение sync (8) перед завершением работы Linux? ,

Старожил здесь. Еще во времена славы TAPE три быстрые синхронизации подряд позволили контроллерам TAPE не просто отсоединять / отсоединять ленточный поток, но и перематывать его, то есть устанавливать FD / rw-head до 0.

"sync; sync; sync" действительно продуктивно использовались только теми из нас, кто порезался с Unix-системами на основе TAPE, то есть приложениями, файлы которых были смонтированы в / var / spool, самом дешевом хранилище, которое когда-либо было возможно. ;)

В руководствах по эксплуатации MIPS Risc / OS есть страница об этом.

Конечно, были более старые системы UNIX, для которых было безопаснее синхронизировать несколько раз, но не все в одной командной строке, как «синхронизация; синхронизация; синхронизация». В середине 80-х это стало дистиллированной до:

Когда вы выключите систему, вы будете синхронизироваться три раза. Ни больше ни меньше. Три должны быть номером синхронизации, а номер синхронизации должен быть три. Четыре раза не синхронизируй и не синхронизируй дважды, за исключением того, что ты продолжаешь синхронизировать в третий раз ...

Я действительно не знаю, откуда взялись три раза, разве что это было весело. Но слово на улице, чтобы сделать это дважды. Не как "sync; sync", а как две отдельные строки на оболочке.

В те времена, скажем, в V7 UNIX, восстановление файловой системы было не таким увлекательным занятием. Вы должны были сделать это вручную, много зная о том, как работает файловая система, и об особенностях таких программ, как dcheck, ncheck и icheck. fsck, если бы у вас это было, не всегда было то, чему вы бы доверяли.

Это начинает звучать как история «мы шли по снегу в обоих направлениях». Ну, у нас не было причудливых команд, таких как перезагрузка или выключение. Когда вы захотели перезагрузить систему, вы синхронизировали файловую систему с синхронизацией, а затем нажали Ctrl-P на консоли, чтобы остановить ее.

Когда команда sync завершилась, ядро ​​запланировало синхронизацию, но не все буферы (включая важнейший суперблок файловой системы) обязательно добрались до диска. Так что было довольно легко запустить синхронизацию и затем остановить все до того, как это стало безопасным.

Повторное выполнение синхронизации было простым делом, занимало время и имело определенную интуитивную привлекательность без необходимости понимать все это или иметь дело со смутными инструкциями, такими как «считать до 10» или чем-то в этом роде.

На справочной странице V7 был даже раздел «ОШИБКА» update:

При запуске обновления, если процессор останавливается так же, как выполняется синхронизация, файловая система может быть повреждена. Это частично связано с аппаратным обеспечением DEC, которое записывает нули при сбое запросов NPR. Исправление будет состоять в том, чтобы sync (1) временно увеличивал системное время как минимум на 30 секунд, чтобы запустить выполнение обновления. Это дало бы 30 секунд льготы для остановки процессора.

(что, кстати, было самым последним в томе 1 руководства V7)

Со временем инструменты файловой системы и программы для выключения и перезагрузки систем стали лучше, чтобы избежать этой проблемы. Фольклор, вуду и системная магия входят в это, когда система ведет себя таинственно. Двойная синхронизация значительно снизила вероятность того, что вам понадобится пинцет, чтобы собрать свою файловую систему, и это стало частью ритуала. Как только вы сделали это несколько раз, вы делаете это, не задумываясь. Тогда кто-то замечает и спрашивает, почему. И ответ такой: «Всегда так делал. Это безопаснее».

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