L'esecuzione di sync (8) è ancora necessaria prima di chiudere Linux?

Vedo ancora che le persone raccomandano l'uso degli sync; sync; sync; sleep 30; haltincantesimi quando parlano di chiudere o riavviare Linux.

Ho eseguito Linux sin dal suo inizio e sebbene questa fosse la procedura consigliata nei giorni BSD 4.2 / 4.3 e SunOS 4, non ricordo che dovevo farlo per almeno gli ultimi dieci anni, durante i quali probabilmente è stato sottoposto a spegnimento / riavvio di Linux forse migliaia di volte.

Ho il sospetto che si tratti di un anacronismo sin dai tempi in cui il kernel non poteva smontare e sincronizzare il filesystem di root e altri filesystem critici richiesti anche durante la modalità single-user (es. / Tmp), e quindi era necessario dirlo esplicitamente di svuotare quanti più dati possibile sul disco.

In questi giorni, senza trovare ancora il codice rilevante nel sorgente del kernel (scavando attraverso http://lxr.linux.no e google), sospetto che il kernel sia abbastanza intelligente da smontare in modo pulito anche il filesystem di root e il filesystem è abbastanza intelligente eseguire effettivamente una sincronizzazione (2) prima di smontare se stesso durante un normale shutdown/ reboot/ poweorff.

È "sync; sync; sync"necessario solo in casi estremi in cui il filesystem non si smonterà in modo pulito (ad es. Guasto del disco fisico) o il sistema è in uno stato che solo forzando un riavvio diretto (8) lo farà uscire dal suo blocco (ad es. Il carico è troppo alto per consentire di programmare il comando di arresto).

Inoltre, non synceseguo mai la procedura prima di smontare i dispositivi rimovibili e non ho mai riscontrato un problema.

Un altro esempio: Xen consente a DomU di ricevere un shutdowncomando da Dom0, questo è considerato un "arresto pulito" senza che nessuno debba effettuare il login e digitare sync; sync; syncprima il magico .

Ho ragione o sono stato fortunato per alcune migliaia di arresti del sistema?

Il motivo per cui le persone eseguono sync; syncprima di a haltè perché il haltcomando non ha arrestato il sistema in modo pulito su Linux più vecchi. Il modo corretto per farlo sui sistemi SYSVr4 è sempre quello di dire a init di passare a un livello di esecuzione diverso.

BSD e SunOS 4 non sono sistemi operativi SYSVr4 ed è per questo che differiscono. Solaris (SunOS 5) è SYSVr4 e Linux seleziona i bit dello standard SYSVr4 che desidera utilizzare.

L'uso di halt è in realtà un modo piuttosto brutto di farlo sulla maggior parte degli UNIX (Linux è una delle eccezioni) poiché in realtà non esegue gli script di init per eseguire operazioni come l'arresto dei processi e lo smontaggio dei dischi, ma semplicemente arresta il processore.

Se puoi garantire che non userai mai e poi mai nessun tipo di sistema UNIX rispetto a Linux, allora puoi continuare a usare halt- se c'è una possibilità che userai altri UNIX, ti consiglio di prendere l'abitudine di usare init _runlevel_o shutdown.

Il shutdowncomando in realtà dice al initprocesso di cambiare il suo livello di esecuzione - in tal modo init quindi procede con l'esecuzione di ciascuno degli script K * init e S * init associati a quel livello di esecuzione. Uno degli script nel livello di esecuzione 0 esegue lo smontaggio dei filesystem.

Su Linux il haltcomando appena chiama il shutdowncomando a meno che il livello di esecuzione è già 0 (spegnimento) o 6 (riavvio) in ogni caso ; quindi nessuna perdita lì.

L'atto di smontare un filesystem usando umountsincronizzerà i dati sul disco prima che lo smonti.

Se hai eseguito sync; sync; haltLinux, ti andrà bene lo stato del filesystem perché gli sviluppatori hanno assicurato che haltfa la cosa giusta ; tuttavia sarebbe più corretto usare:shutdown now

L'uso di più syncchiamate era di concedere al sistema operativo e ai dischi il tempo di svuotare le code di scrittura. "sync; sync; sync"non era considerato così utile; uno ha fatto "sync<cr> sync<cr> sync<cr"e il ritardo mentre il tuo ASR-33 ha fatto il ritorno / newline del trasporto ha fornito un ritardo sufficiente. Halt chiamava sempre la sincronizzazione; la domanda era se ci sarebbe stato abbastanza tempo per svuotare le code prima che fosse tolta l'alimentazione.

Il poster originale sync; sleep 30è più in linea con ciò che era previsto.

Posso solo parlare del motivo per cui potresti emettere syncpiù volte. Il comando pianifica il flush su disco ma ritorna prima che il flush effettivo sia completato. Qualsiasi synccomando successivo verrà bloccato fino a quando non è in corso un flush in sospeso prima di pianificare un altro flush ed uscire. Pertanto, sync; syncgarantisce un flush sincrono. Non è necessario farlo più di 2 volte, né portare sleepnel mix.

Quelli di voi che ci dicono tutto ciò che "sync; sync; sync" non ha scopo stanno rivelando la tua età.

Ai vecchi tempi, prima che Unix fosse qualcosa per adolescenti, dovevamo usare TAPE per le nostre esigenze di streaming / backup. Spesso, montavamo un filesystem basato su nastro su cui eseguire lo streaming dei backup e così via. Questa lunga e sottile banda di nastro magnetico di plastica era tutta una parte di noi, per archiviare i nostri file su ...

Il comando 'sync; sync; sync' era un modo in cui si poteva dire a queste vecchie macchine a nastro di riavvolgere fino alla fine (prima dell'arresto) - avevano a bordo un firmware che avrebbe ricevuto il cmd di sincronizzazione (come tutti i buoni filesystem fare), e se fosse seguito quasi immediatamente da altri due comandi del buffer di sincronizzazione, l'unità a nastro stessa interpreterebbe questo per significare "riavvolgere il nastro e smontarlo". Non c'era modo di dire al riavvolgimento dell'unità a nastro, al di là di questo metodo, e in qualche modo si bloccava. Questa abitudine è poi passata in parola quando i dischi rigidi sono diventati più disponibili - noi vecchi operatori crusty non si limitano a realloc ( ) la nostra memoria muscolare lo sai! Credo che abbia raggiunto lo status di folklore subito dopo che i nastri sono diventati meno comuni e i dischi rigidi sono diventati più disponibili, ma ha ancora i suoi usi per quelli di noi con unità a nastro.