Czy istnieje filozofia prawdy, którą należy zsynchronizować; synchronizacja; synchronizacja; zsynchronizować?

Kiedy po raz pierwszy zapoznałem się z Linuksem, pracując w Cisco Systems w 2000 roku, dowiedziałem się o zaletach syncpolecenia, używanego do opróżniania buforów na dysk, aby zapobiec uszkodzeniu systemu plików / utracie danych. Powiedziano mi nie tylko tamtejszym współpracownikom, ale także znajomym w college'u, że zawsze biegają sync„kilka” lub „kilka” razy, to znaczy może 5–10 razy, a nie tylko raz.

Od tego czasu kontynuuję ten nawyk, ale czy ma to jakąś wartość? Czy ktoś jeszcze to słyszał? A co najważniejsze, czy ktoś może przedstawić dobre uzasadnienie / dowody empiryczne przemawiające przeciwko pomysłowi, że trzeba działać syncwięcej niż jeden raz, aby był skuteczny?

Słyszałem (przepraszam, nie pamiętam gdzie) synctrzykrotnie wpisując polecenie (jak w S Y N C Return:, poczekaj na monit, powtórz, powtórz). Przeczytałem również, że pochodzenie było szczególnym systemem, w którym dysk zająłby kilka sekund, aby zakończyć opróżnianie buforów, nawet po tym, jak poinformował system operacyjny, że wszystko jest w porządku. Dwukrotne wpisanie polecenia dało dyskowi wystarczająco dużo czasu na osiedlenie się. Wygląda na to, że z biegiem lat cel został zapomniany, a rada została skrócona, ponieważ sync; sync; syncnie przyniosłoby to pożądanego efektu (ponieważ dysk zgłosił „wszystko czyste”, druga i trzecia synchronizacja zakończyły się natychmiast, a monit wróciłby zbyt wcześnie).

Nigdy nie słyszałem o systemie, w którym wiele syncoperacji ma jakiekolwiek zastosowanie, i jestem bardzo sceptyczny. Uważam to za legendę miejską. Z drugiej strony uważam za wysoce wiarygodne, że będą systemy, w których należy poczekać kilka sekund po synchronizacji i przed wyłączeniem zasilania.

Googling prowadzi do kilku niezależnych zbieżnych analiz, np. The Legend of sync . Zobacz także Czy wykonanie synchronizacji (8) jest nadal wymagane przed zamknięciem systemu Linux? .

Old-timer tutaj. W czasach świetności TAPE, 3 szybkie synchronizacje z rzędu były sposobem na poinformowanie kontrolerów TAPE, aby nie tylko odłączyły / odpakowowały strumień taśmy, ale także przewinęły go do tyłu, tj. Ustawiły FD / rw-head do 0.

„sync; sync; sync” był tak naprawdę produktywnie używany tylko przez tych z nas, którzy obcinają zęby za pomocą Uniksa opartego na TAPE, tj. aplikacji, których pliki były montowane na / var / spool, najtańszej dostępnej wówczas pamięci. ;)

Instrukcje obsługi MIPS Risc / OS mają stronę na tym ..

Z pewnością istniały starsze systemy UNIX, dla których bezpieczniej było synchronizować więcej niż jeden raz, ale nie wszystkie w jednym wierszu poleceń jako „synchronizacja; synchronizacja; synchronizacja”. W połowie lat 80. destylowano to do:

Kiedy wyłączysz system, zsynchronizujesz trzy razy. Nie więcej nie mniej. Trzy to liczba synchronizacji, a liczba synchronizacji to trzy. Czterokrotnie nie synchronizujesz, ani synchronizujesz dwa razy, tyle że synchronizujesz po raz trzeci ...

Naprawdę nie wiem, skąd trzy razy się wzięły, może poza tym, że było fajnie. Ale słowo na ulicy, żeby to zrobić dwa razy. Nie jako „synchronizacja; synchronizacja”, ale jako dwie osobne linie na powłoce.

W czasach, powiedzmy, V7 UNIX, naprawa systemu plików nie była świetną zabawą. Trzeba było to zrobić ręcznie, wiedząc dużo o tym, jak działa system plików i o osobliwościach programów takich jak dcheck, ncheck i icheck. fsck, gdybyś miał, nie zawsze byłby czymś, komu można zaufać.

Zaczyna to brzmieć jak historia „przeszliśmy przez śnieg w obie strony”. Cóż, nie mieliśmy wymyślnych poleceń, takich jak ponowne uruchomienie lub wyłączenie. Kiedy chciałeś zrestartować system, zsynchronizowałeś system plików z synchronizacją, a następnie nacisnąłeś Ctrl-P na konsoli, aby go zatrzymać.

Kiedy polecenie synchronizacji zakończyło się, jądro zaplanowało synchronizację, ale nie wszystkie bufory (w tym superblok systemu plików) koniecznie dotarły na dysk. Synchronizacja była więc dość łatwa, a potem zatrzymywanie, zanim było bezpieczne.

Ponowne uruchomienie synchronizacji było łatwe, wymagało czasu i było intuicyjne, bez konieczności rozumienia wszystkiego lub radzenia sobie z niejasnymi instrukcjami, takimi jak „policz do 10” lub coś w tym rodzaju.

Na stronie podręcznika V7 była nawet sekcja BŁĄD, w której updatenapisano:

Gdy uruchomiona jest aktualizacja, jeśli procesor zostanie zatrzymany w trakcie wykonywania synchronizacji, system plików może zostać uszkodzony. Jest to częściowo spowodowane sprzętem DEC, który zapisuje zera w przypadku niepowodzenia żądań NPR. Rozwiązaniem byłoby tymczasowe zwiększenie synchronizacji (1) o co najmniej 30 sekund w celu uruchomienia aktualizacji. Dałoby to 30 sekund na zatrzymanie procesora.

(która, nawiasem mówiąc, była ostatnią rzeczą w tomie 1 instrukcji V7)

Z czasem narzędzia systemu plików i programy do zamykania i ponownego uruchamiania systemów stawały się coraz lepsze, aby uniknąć uporania się z tym problemem. Folklor, voodoo i magia systemowa wchodzą w nią, gdy system zachowuje się w tajemniczy sposób. Dwukrotna synchronizacja sprawiła, że ​​znacznie mniej prawdopodobne było, że będziesz musiał wydostać się z pęsety, aby złożyć swój system plików z powrotem, więc stało się to częścią rytuału. Gdy robisz to już kilka razy, robisz to bez zastanowienia. Wtedy ktoś zauważa i pyta, dlaczego. Odpowiedź brzmi: „Zawsze tak robiłem. Jest bezpieczniej”.

Nie twierdzę, że jest to wiarygodne i mogę się mylić co do niektórych szczegółów. Ale myślę, że jest dość blisko pochodzenia.