Cuando me presentaron por primera vez a Linux, trabajando en Cisco Systems en 2000, me enseñaron los méritos del sync
comando, que solía vaciar los buffers al disco para evitar la corrupción del sistema de archivos / pérdida de datos. No solo me dijeron los compañeros de trabajo allí, sino también amigos en la universidad, que siempre corrían sync
"unas pocas" o "muchas", es decir, tal vez 5 a 10 veces, en lugar de una sola vez.
He continuado con este hábito desde entonces, pero ¿hay algún mérito en esto? ¿Alguien más ha escuchado esto? Y lo más importante, ¿puede alguien proporcionar una buena justificación / evidencia empírica a favor / en contra de la idea de que necesita correr sync
más de una vez para que sea efectiva?
fuente
sync; sync; sync; sync
el título, y a veces lo escribo de esa manera, también escuché que me lo explicaron de la misma manera, es decir, sincronizar, esperar, sincronizar de nuevo, esperar, etc.Veterano aquí. En los días de gloria de TAPE, 3 sincronizaciones rápidas seguidas eran una forma de decirle a los controladores TAPE que no solo desenlazaran / desenrollaran el flujo de cinta, sino que también lo rebobinasen, es decir, configuraran el cabezal FD / rw a 0.
"sync; sync; sync" en realidad solo fue utilizado, productivamente, por aquellos de nosotros que cortamos los dientes con Unix's basado en TAPE, es decir, aplicaciones cuyos archivos fueron montados en / var / spool, el almacenamiento más barato posible en ese momento. ;)
Los manuales del operador MIPS Risc / OS tienen una página sobre esto.
fuente
Ciertamente, había sistemas UNIX más antiguos para los que era más seguro sincronizar más de una vez, pero no todos en una línea de comando como "sync; sync; sync". A mediados de los años 80, esto se destiló para:
Realmente no sé de dónde vinieron las tres veces, excepto tal vez que fue divertido. Pero la palabra en la calle para hacerlo dos veces. No como "sincronización; sincronización", sino como dos líneas separadas en el shell.
En los días de, digamos, V7 UNIX, la reparación del sistema de archivos no era muy divertida. Tenías que hacerlo a mano, sabiendo mucho sobre cómo funcionaba el sistema de archivos y las idiosincrasias de programas como dcheck, ncheck e icheck. fsck, si lo tuvieras, no siempre es algo en lo que confiarías.
Esto comienza a sonar como una historia de "caminamos cuesta arriba en ambos sentidos". Bueno, no teníamos comandos sofisticados como reiniciar o apagar. Cuando deseaba reiniciar el sistema, sincronizaba el sistema de archivos con sincronización y luego presiona Ctrl-P en la consola para detenerlo.
Cuando salió el comando de sincronización, el núcleo había programado la sincronización, pero no todos los búferes (incluido el superbloque del sistema de archivos) habían llegado necesariamente al disco. Por lo tanto, fue bastante fácil ejecutar la sincronización y luego detener las cosas antes de que fuera seguro.
Ejecutar la sincronización nuevamente fue algo fácil de hacer, tomó el tiempo y tuvo un cierto atractivo intuitivo sin tener que entenderlo todo, o tratar con instrucciones vagas como "contar hasta 10" o algo así.
Incluso había una sección de ERROR en la página de manual de V7 para
update
también decir:(que, por cierto, fue lo último en el Volumen 1 de los manuales de V7)
Con el tiempo, las herramientas del sistema de archivos y los programas para apagar y reiniciar los sistemas mejoraron para evitar lidiar con esto. El folklore, el vudú y la magia del sistema entran en juego cuando el sistema se comporta misteriosamente. La sincronización dos veces hizo que fuera mucho menos probable que tuviera que sacar las pinzas para volver a armar su sistema de archivos, por lo que se convirtió en parte del ritual. Una vez que lo has hecho varias veces, lo haces sin pensar. Entonces alguien se da cuenta y pregunta por qué. Y la respuesta es algo así como: "Siempre lo hice así. Es más seguro".
No afirmaré que esto es autoritario, y podría estar equivocado sobre algunos de los detalles. Pero creo que está bastante cerca del origen.
fuente