C'è verità nella filosofia che dovresti sincronizzare; sync; sync; sync?

Quando sono stato introdotto per la prima volta su Linux, lavorando su Cisco Systems nel 2000, mi hanno insegnato i meriti del synccomando, usato per scaricare i buffer su disco per prevenire la corruzione / perdita di dati del filesystem. Mi è stato detto non solo dai colleghi lì, ma dagli amici del college di correre sempre sync"poche" o "un sacco" di volte, cioè forse 5-10 volte, invece di una sola volta.

Ho continuato questa abitudine da allora, ma c'è qualche merito in questo? Qualcun altro l'ha mai sentito? E, soprattutto, qualcuno può fornire prove razionali / empiriche a favore / contro l'idea che è necessario eseguire syncpiù di una volta affinché sia ​​efficace?

L'ho sentito (scusate, ho dimenticato dove) digitando il synccomando tre volte (come in S Y N C Return:, attendere il prompt, ripetere, ripetere). Ho anche letto che l'origine era un sistema particolare in cui ci sarebbero voluti un paio di secondi affinché il disco finisse di svuotare i suoi buffer, anche dopo aver detto al sistema operativo che tutto andava bene. Digitando il comando altre due volte, il disco ha avuto il tempo di sistemarsi. Sembra che nel corso degli anni lo scopo sia stato dimenticato, e il consiglio è stato abbreviato in quanto sync; sync; syncnon avrebbe avuto l'effetto desiderato (poiché il disco aveva riportato il "tutto chiaro", la seconda e la terza sincronizzazione si sarebbero completate all'istante e il prompt sarebbe tornato troppo presto).

Non ho mai sentito parlare di un sistema in cui più syncoperazioni sono utili e sono altamente scettico. Lo considero una leggenda urbana. D'altra parte, trovo altamente credibile che esistano sistemi in cui dovresti aspettare un paio di secondi dopo la sincronizzazione e prima di spegnere.

Googling porta ad alcune analisi concorrenti indipendenti, ad esempio The Legend of sync . Vedi anche L' esecuzione di sync (8) è ancora necessaria prima di chiudere Linux? .

Old-timer qui. Nei giorni di gloria di TAPE, 3 sincronizzazioni rapide di seguito erano un modo per dire ai controller TAPE di non solo scollegare / annullare il pool del flusso di nastro, ma anche di riavvolgerlo, ovvero impostare FD / rw-head a 0.

"sync; sync; sync" è stato utilizzato solo in modo produttivo da quelli di noi che si sono tagliati i denti con Unix basato su TAPE, ovvero app i cui file erano montati su / var / spool, lo spazio di archiviazione più economico possibile al momento. ;)

I manuali dell'operatore MIPS Risc / OS hanno una pagina su questo ..

Esistevano certamente sistemi UNIX meno recenti per i quali era più sicuro sincronizzare più di una volta, ma non tutti su una riga di comando come "sync; sync; sync". A metà degli anni '80, questo divenne distillato per:

Quando si spegne il sistema, si sincronizzerà tre volte. Ne più ne meno. Tre sono il numero della sincronizzazione e il numero della sincronizzazione è tre. Non sincronizzerai quattro volte, né sincronizzerai due volte, tranne che procederai alla sincronizzazione una terza volta ...

Non so davvero da dove vengano le tre volte, tranne forse che è stato divertente. Ma la parola sulla strada per farlo due volte. Non come "sync; sync", ma come due linee separate sulla shell.

Ai tempi di, diciamo, V7 UNIX, la riparazione del file system non era molto divertente. Dovevi farlo a mano, sapendo molto su come funzionava il filesystem e sulle idiosincrasie di programmi come dcheck, ncheck e icheck. fsck, se ce l'hai, non è sempre stato qualcosa di cui ti fidi.

Sta iniziando a sembrare una storia "abbiamo camminato attraverso la neve in salita in entrambi i modi". Bene, non avevamo comandi fantasiosi come riavvio o spegnimento. Quando volevi riavviare il sistema, hai sincronizzato il filesystem con sync e quindi hai premuto Ctrl-P sulla console per arrestarlo.

Quando il comando di sincronizzazione è terminato, il kernel aveva programmato la sincronizzazione, ma non tutti i buffer (incluso l'importante superblocco del filesystem) erano necessariamente arrivati ​​sul disco. Quindi è stato abbastanza facile eseguire la sincronizzazione e quindi interrompere le cose prima che fosse sicuro.

Eseguire di nuovo la sincronizzazione è stata una cosa facile da fare, ha impiegato molto tempo e ha avuto un certo fascino intuitivo senza dover capire tutto o gestire vaghe istruzioni come "contare fino a 10" o qualcosa del genere.

C'era anche una sezione BUG nella pagina man di V7 per updateanche detto:

Con l'aggiornamento in esecuzione, se la CPU viene arrestata mentre viene eseguita la sincronizzazione, un file system può essere danneggiato. Ciò è in parte dovuto all'hardware DEC che scrive zeri quando le richieste NPR falliscono. Una correzione sarebbe quella di avere sync (1) incrementare temporaneamente il tempo di sistema di almeno 30 secondi per attivare l'esecuzione dell'aggiornamento. Ciò darebbe 30 secondi di grazia per arrestare la CPU.

(che, a proposito, è stata l'ultima cosa nel volume 1 dei manuali V7)

Nel tempo, gli strumenti del filesystem e i programmi per l'arresto e il riavvio dei sistemi sono migliorati per evitare di affrontarli. Folclore, voodoo e magia del sistema entrano in esso quando il sistema si comporta in modo misterioso. La sincronizzazione due volte ha reso molto meno probabile che avresti dovuto estrarre le pinzette per rimettere insieme il tuo filesystem, quindi è diventato parte del rituale. Una volta che lo hai fatto un sacco di volte, lo fai senza pensare. Quindi qualcuno si accorge e chiede perché. E la risposta è qualcosa del tipo: "Sempre fatto così. È più sicuro".

Non pretenderò che questo sia autorevole e potrei sbagliarmi su alcuni dettagli. Ma penso che sia abbastanza vicino all'origine.