Чи є правда у філософії, яку слід синхронізувати; синхронізація; синхронізація; синхронізація?

Коли я вперше був представлений в Linux, працюючи в Cisco Systems в 2000 році, мене вчили достоїнства syncкоманди, яка використовується для відмивання буферів на диску для запобігання пошкодження файлової системи / втрати даних. Мені сказали не тільки співробітники там, але й друзі в коледжі, щоб завжди пробігати sync"кілька" чи "купу" разів, тобто, можливо, 5 - 10 разів, а не один раз.

Я продовжував цю звичку з тих пір, але чи є в цьому заслуга? Хтось ще коли-небудь чув це? І найголовніше, чи може хтось надати хороші обґрунтування / емпіричні докази / проти думки про те, що syncдля її ефективності потрібно працювати не один раз?

Я почув це (вибачте, забуваю куди), як набрав syncкоманду тричі (як у:, S Y N C Returnчекайте підказки, повторіть, повторіть). Я також читав, що джерелом була конкретна система, де пішло б кілька секунд, щоб диск закінчив промивати свої буфери, навіть після того, як він сказав операційній системі, що все в порядку. Введення команди ще вдвічі дало диску достатньо часу для розселення. Здається, що з роками мета була забута, і поради були скорочені, sync; sync; syncщо не дало б бажаного ефекту (оскільки диск повідомив про "все зрозуміло", другий і третій синхронізації завершаться миттєво, і підказка повернеться занадто рано).

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

Гуглінг призводить до декількох незалежних паралельних аналізів, наприклад, Легенда синхронізації . Дивіться також Чи потрібне виконання синхронізації (8) перед тим, як вимкнути Linux? .

Тут старожили. Ще в часи слави TAPE, 3 швидкі синхронізації поспіль були способом сказати контролерам TAPE не просто від’єднувати / відкручувати стрічковий потік, але також перемотувати його назад, тобто встановлювати FD / rw-head до 0.

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

Посібники з операторів MIPS Risc / OS мають на цьому сторінку.

Звичайно, існували старіші системи UNIX, для яких було безпечніше синхронізувати не один раз, але не всі в одному командному рядку як "синхронізація; синхронізація; синхронізація". У середині 80-х це перегнали на:

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

Я насправді не знаю, звідки тричі родом, крім, можливо, що це було весело. Але слово на вулиці зробити це двічі. Не як "sync; sync", а як два окремих рядки на оболонці.

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

Це починає звучати як історія "ми пішли по снігу в гору обома шляхами" історія. Ну, у нас не було таких фантазійних команд, як перезавантаження чи вимкнення. Коли ви хотіли перезавантажити систему, ви синхронізували файлову систему, а потім натискаєте Ctrl-P на консолі, щоб зупинити її.

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

Знову запустити синхронізацію було легко, зайняв час і мав певну інтуїтивну привабливість, не маючи цього все розуміти, чи мати справу з нечіткими інструкціями на кшталт "рахувати до 10" чи щось подібне.

На сторінці людини V7 був навіть розділ BUG, ​​який updateтакож сказав:

При запуску оновлення, якщо ЦП зупиняється саме під час синхронізації, файлова система може бути пошкоджена. Частково це пов'язано з обладнанням DEC, яке записує нулі, коли запити NPR не спрацьовують. Виправленням було б синхронізація (1) тимчасово збільшити системний час принаймні на 30 секунд, щоб запустити виконання оновлення. Це дасть тривалість 30 секунд для зупинки процесора.

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

З часом інструменти файлової системи та програми для вимкнення та перезавантаження систем стали краще уникати цього. Фольклор, вуду та системна магія входять до нього, коли система поводиться загадково. Двічі синхронізація зробила набагато меншою ймовірність того, що вам доведеться дістати пінцети, щоб повернути вашу файлову систему, і це стало частиною ритуалу. Коли ви це зробили купу разів, ви робите це, не замислюючись. Потім хтось помічає і запитує, чому. А відповідь - щось на зразок: "Завжди роби це так. Безпечніше".

Я не буду стверджувати, що це авторитетно, і я можу помилитися в деяких деталях. Але я думаю, що це досить близько до походження.