A execução do sync (8) ainda é necessária antes de desligar o linux?

Ainda vejo pessoas recomendando o uso de sync; sync; sync; sleep 30; haltencantamentos quando se fala em desligar ou reiniciar o Linux.

Estou executando o Linux desde o seu início e, embora esse tenha sido o procedimento recomendado nos dias BSD 4.2 / 4.3 e SunOS 4, não me lembro de ter feito isso pelo menos nos últimos dez anos, durante os quais provavelmente passou pelo desligamento / reinicialização do Linux talvez milhares de vezes.

Eu suspeito que isso seja um anacronismo desde os dias em que o kernel não conseguiu desmontar e sincronizar o sistema de arquivos raiz e outros sistemas de arquivos críticos necessários, mesmo durante o modo de usuário único (por exemplo, / tmp), e, portanto, era necessário dizer explicitamente para liberar o máximo de dados possível para o disco.

Hoje em dia, sem encontrar o código relevante na fonte do kernel (pesquisando em http://lxr.linux.no e google), suspeito que o kernel seja inteligente o suficiente para desmontar até o sistema de arquivos raiz e o sistema de arquivos é inteligente o suficiente efetivamente fazer uma sincronização (2) antes de desmontar-se durante um shutdown/ reboot/ normal poweorff.

A "sync; sync; sync"só é necessário em casos extremos, onde o sistema de arquivos não vai desmontar limpa (por exemplo, falha de disco físico) ou o sistema está em um estado que só forçando um reboot direta (8) irá tirá-lo do seu congelamento (por exemplo, a carga é muito alto para permitir agendar o comando shutdown).

Também nunca faço o syncprocedimento antes de desmontar dispositivos removíveis e nunca encontro um problema.

Outro exemplo - o Xen permite que o DomU receba um shutdowncomando do Dom0, isso é considerado um "desligamento limpo" sem que ninguém precise fazer login e digitar o mágico sync; sync; syncprimeiro.

Estou certo ou tive a sorte de alguns milhares de desligamentos do sistema?

A razão pela qual as pessoas executariam sync; syncantes de um halté porque o haltcomando não desligaria o sistema corretamente em linuxes mais antigos. A maneira correta de fazer isso nos sistemas SYSVr4 sempre é dizer ao init para passar para um nível de execução diferente.

BSD e SunOS 4 não são sistemas operacionais SYSVr4 e é por isso que diferem. O Solaris (SunOS 5) é o SYSVr4 e o Linux seleciona bits do padrão SYSVr4 que deseja usar.

Usar o halt é realmente uma maneira muito ruim de fazer isso na maioria dos UNIXes (o Linux é uma das exceções), pois na verdade não é executado nos scripts init para executar coisas como parar processos e desmontar discos - apenas interrompe o processador.

Se você pode garantir que você nunca mais nunca, nunca usar qualquer tipo de sistema UNIX do que o Linux, então você pode continuar usando halt- se há uma chance de que você vai usar outros UNIXes então eu recomendo entrar no hábito de usar init _runlevel_ou shutdown.

O shutdowncomando diz realmente o initprocesso para alterar seu nível de execução nível de execução - ao fazê-lo o init então começa a executar cada um dos k * scripts de inicialização e S * scripts de inicialização associados a esse nível de execução. Um dos scripts no nível de execução 0 executa a desmontagem dos sistemas de arquivos.

No Linux, o haltcomando apenas chama o shutdowncomando, a menos que o nível de execução já seja 0 (desligando) ou 6 (reiniciando) de qualquer maneira ; então não há perda lá.

O ato de desmontar um sistema de arquivos usando umountsincronizará os dados com o disco antes de desmontá-lo.

Se você estiver rodando sync; sync; haltno Linux, estará bem com o estado do sistema de arquivos porque os desenvolvedores garantiram que haltfaz a coisa certa ; no entanto, seria mais correto usar:shutdown now

O uso de várias syncchamadas foi para permitir que o SO e os discos limpassem as filas de gravação. "sync; sync; sync"não foi considerado tão útil; um fez "sync<cr> sync<cr> sync<cr"e o atraso, enquanto o seu ASR-33 fez o retorno de carro / nova linha, desde que o atraso fosse suficiente. Halt sempre chamava de sincronização; a questão era se haveria tempo suficiente para liberar as filas antes que a energia fosse removida.

O pôster original sync; sleep 30está mais de acordo com o que foi planejado.

Posso única falar por que você iria emitir syncvárias vezes. O comando agenda a liberação para o disco, mas retorna antes que a liberação real seja concluída. Qualquer synccomando subseqüente será bloqueado até que qualquer liberação pendente esteja em andamento antes de agendar outra liberação e saída. Portanto, sync; syncgarante uma descarga síncrona. Você não precisa fazer isso mais de duas vezes, nem trazer sleeppara a mistura.

Aqueles de vocês que estão dizendo a todos que "sincronizar; sincronizar; sincronizar" não têm propósito, estão revelando sua idade.

Antigamente, antes do Unix ser algo para adolescentes, costumávamos usar o TAPE para atender às nossas necessidades de streaming / backup. Muitas vezes, montávamos um sistema de arquivos baseado em fita para transmitir backups e assim por diante. Esta banda longa e fina de fita plástica magnética era tudo que alguns de nós possuímos, para armazenar nossos arquivos ..

O comando 'sync; sync; sync' era uma maneira de dizer a essas máquinas de fita antigas que se rebobinavam até o fim (antes do desligamento) - elas tinham firmware interno que receberia o cmd de sincronização (como todos os bons sistemas de arquivos do) e se fosse seguido quase imediatamente por mais dois comandos do buffer de sincronização, a própria unidade de fita interpretaria isso como "rebobinar a fita e desmontá-la". Não havia como dizer para a unidade de fita retroceder, além desse método, e meio que ficou presa. Esse hábito passou à palavra quando os discos rígidos se tornaram mais disponíveis - nós, os velhos operadores não apenas realocamos ( ) nossa memória muscular, você sabe! Acredito que alcançou o status de folclore logo depois que as fitas se tornaram menos comuns e os discos rígidos se tornaram mais disponíveis, mas ainda tem seus usos para aqueles de nós com unidades de fita.