sync es una llamada estándar del sistema operativo Unix que envía todos los datos de los buffers del sistema de archivos del núcleo a un almacenamiento no volátil , es decir, datos que se han programado para su escritura mediante llamadas del sistema de E/S de bajo nivel . Las capas de E/S de nivel superior, como stdio, pueden mantener sus propios buffers separados.
Como función en C , la sync()llamada se declara normalmente como void sync(void)en <unistd.h>. La llamada del sistema también está disponible a través de una utilidad de línea de comandos también llamada sync y funciones con nombres similares en otros lenguajes como Perl y Node.js (en el módulo fs).
La llamada del sistema relacionada fsync()confirma solo los datos almacenados en búfer relacionados con un descriptor de archivo especificado . [1] fdatasync() También está disponible para escribir solo los cambios realizados a los datos en el archivo, y no necesariamente los metadatos relacionados con el archivo. [2]
Algunos sistemas Unix ejecutan una especie de demonio de vaciado o actualización , que llama a la función sync de forma regular. En algunos sistemas, el demonio cron hace esto, y en Linux lo manejaba el demonio pdflush, que fue reemplazado por una nueva implementación y finalmente eliminado del kernel de Linux en 2012. [3] Los buffers también se vacían cuando los sistemas de archivos se desmontan o se vuelven a montar en modo de solo lectura , [4] por ejemplo antes de apagar el sistema.
Algunas aplicaciones, como LibreOffice , también llaman a la función de sincronización para guardar la información de recuperación en un intervalo.
Para proporcionar una durabilidad adecuada , las bases de datos deben utilizar alguna forma de sincronización para asegurarse de que la información escrita haya llegado a un almacenamiento no volátil en lugar de simplemente almacenarse en un caché de escritura basado en memoria que se perdería si fallara la energía. PostgreSQL , por ejemplo, puede usar una variedad de llamadas de sincronización diferentes, incluidas fsync()y fdatasync(), [5] para que las confirmaciones sean duraderas. [6] Desafortunadamente, para cualquier cliente individual que escriba una serie de registros, un disco duro giratorio solo puede confirmar una vez por rotación, lo que produce, en el mejor de los casos, unos pocos cientos de confirmaciones de este tipo por segundo. [7] Por lo tanto, desactivar el requisito fsync puede mejorar en gran medida el rendimiento de las confirmaciones, pero a expensas de introducir potencialmente corrupción en la base de datos después de una falla.
Las bases de datos también emplean archivos de registro de transacciones (normalmente mucho más pequeños que los archivos de datos principales) que tienen información sobre cambios recientes, de modo que los cambios se pueden rehacer de forma fiable en caso de fallo; entonces, los archivos de datos principales se pueden sincronizar con menos frecuencia.
Para evitar cualquier pérdida de datos, fsync()se deben comprobar los valores de retorno de porque al realizar operaciones de E/S que están almacenadas en búfer por la biblioteca o el núcleo, es posible que no se informen errores en el momento de usar la write()llamada del sistema o la fflush()llamada, ya que los datos pueden no escribirse en un almacenamiento no volátil sino solo en la memoria caché de páginas . En cambio, los errores de escrituras a menudo se informan durante las llamadas del sistema a fsync()o msync(). close()[ 8] Antes de 2018, fsync()el comportamiento de Linux en determinadas circunstancias no informaba el estado de error, [9] [10] Se propuso un cambio de comportamiento el 23 de abril de 2018. [11]
Los discos duros pueden utilizar de forma predeterminada su propia caché de escritura volátil para almacenar en búfer las escrituras, lo que mejora enormemente el rendimiento a la vez que introduce la posibilidad de que se pierdan escrituras. [12] Herramientas como hdparm -F indicarán al controlador del HDD que limpie el búfer de la caché de escritura en el disco. El impacto en el rendimiento de desactivar la caché es tan grande que incluso la comunidad FreeBSD, normalmente conservadora, rechazó deshabilitar la caché de escritura de forma predeterminada en FreeBSD 4.3. [13]
En SCSI y en SATA con Native Command Queuing (pero no en ATA simple, incluso con TCQ) el host puede especificar si desea ser notificado de finalización cuando los datos llegan a los platos del disco o cuando llegan al búfer del disco (caché integrado). Suponiendo una implementación de hardware correcta, esta característica permite que se use el caché integrado del disco mientras se garantiza la semántica correcta para llamadas del sistema como fsync. [14] Esta característica de hardware se llama Force Unit Access (FUA) y permite consistencia con menos sobrecarga que vaciando todo el caché como se hace para los discos ATA (o SATA no NCQ). [15] Aunque Linux habilitó NCQ alrededor de 2007, no habilitó SATA/NCQ FUA hasta 2012, citando la falta de soporte en las primeras unidades. [16] [17]
Firefox 3.0, lanzado en 2008, introdujo fsyncllamadas al sistema que degradaron su rendimiento; la llamada se introdujo para garantizar la integridad de la base de datos SQLite incorporada . [18] El director técnico de Linux Foundation, Theodore Ts'o , afirma que no hay necesidad de "temer a fsync", y que la verdadera causa de la lentitud de Firefox 3 es el uso excesivo de . [19] Sin embargo, también admite (citando a Mike Shaver ) que fsync
En algunas configuraciones de Linux bastante comunes, especialmente cuando se usa el sistema de archivos ext3 en el modo "data=ordered", llamar a fsync no solo vacía los datos del archivo en el que se llama, sino todos los datos almacenados en búfer para ese sistema de archivos. [20]