Quando fui apresentado ao Linux pela primeira vez, trabalhando na Cisco Systems em 2000, aprendi os méritos do sync
comando, usado para liberar buffers em disco para evitar corrupção no sistema de arquivos / perda de dados. Foi-me dito não apenas por colegas de trabalho lá, mas por amigos na faculdade que sempre executam sync
"algumas" ou "várias" vezes, ou seja, talvez 5 a 10 vezes, em vez de apenas uma vez.
Continuei esse hábito desde então, mas há algum mérito nisso? Alguém mais já ouviu isso? E o mais importante, alguém pode fornecer uma boa justificativa / evidência empírica a favor / contra a idéia de que você precisa executar sync
mais de uma vez para que seja eficaz?
fonte
sync; sync; sync; sync
o título, e às vezes digito dessa maneira, também ouvi isso me ser explicado da mesma forma, ou seja, sincronizar, esperar, sincronizar novamente, esperar, etc.Veterano aqui. Nos dias de glória do TAPE, três sincronizações rápidas seguidas eram uma maneira de instruir os controladores do TAPE a não apenas desassociar / desenrolar o fluxo de fita, mas também a retroceder, ou seja, definir o FD / rw-head para 0.
"sync; sync; sync" foi realmente usado apenas de maneira produtiva por aqueles que cortaram os dentes com o Unix baseado em TAPE, ou seja, aplicativos cujos arquivos foram montados em / var / spool, o armazenamento mais barato possível na época. ;)
Os manuais do operador do MIPS Risc / OS têm uma página nesta ..
fonte
Certamente havia sistemas UNIX mais antigos para os quais era mais seguro sincronizar mais de uma vez, mas nem todos em uma linha de comando como "sync; sync; sync". Em meados dos anos 80, isso se tornou destilado para:
Eu realmente não sei de onde vieram as três vezes, exceto talvez que tenha sido divertido. Mas a palavra na rua para fazê-lo duas vezes. Não como "sync; sync", mas como duas linhas separadas no shell.
Nos dias de, digamos, V7 UNIX, o reparo do sistema de arquivos não era muito divertido. Você precisava fazer isso manualmente, sabendo muito sobre como o sistema de arquivos funcionava e as idiossincrasias de programas como dcheck, ncheck e icheck. fsck, se você tivesse, nem sempre era algo em que você confiaria.
Isso está começando a soar como uma história de "andamos pela neve subindo os dois lados". Bem, não tínhamos comandos sofisticados, como reinicialização ou desligamento. Quando você queria reiniciar o sistema, sincronizou o sistema de arquivos com a sincronização e pressionou Ctrl-P no console para interrompê-lo.
Quando o comando sync foi encerrado, o kernel havia programado a sincronização, mas nem todos os buffers (incluindo o superbloco do sistema de arquivos mais importante) o fizeram necessariamente no disco. Por isso, era muito fácil executar a sincronização e interromper as coisas antes de estarem seguras.
Executar a sincronização novamente era uma tarefa fácil, demorava um tempo e tinha um certo apelo intuitivo, sem ter que entender tudo, ou lidar com instruções vagas como "conte até 10" ou algo assim.
Havia até uma seção de BUG na página de manual do V7 para
update
também dizer:(que, a propósito, foi a última coisa no volume 1 dos manuais da V7)
Com o tempo, as ferramentas do sistema de arquivos e os programas para desligar e reiniciar os sistemas ficaram melhores para evitar lidar com isso. Folclore, vodu e magia do sistema entram nela quando o sistema se comporta misteriosamente. A sincronização duas vezes tornava muito menos provável que você tivesse que usar as pinças para montar seu sistema de arquivos, para que isso se tornasse parte do ritual. Depois de fazer isso várias vezes, você faz isso sem pensar. Então alguém percebe e pergunta o porquê. E a resposta é algo como: "Sempre faça dessa maneira. É mais seguro".
Não vou afirmar que isso é autoritário e posso estar errado sobre alguns dos detalhes. Mas acho que é bem próximo da origem.
fonte