sync es una llamada de sistema estándar en el sistema operativo Unix , que compromete todos los datos del sistema de archivos del kernel en búferes de almacenamiento no volátiles , es decir, datos que han sido programados para escritura a través de llamadas al sistema de E / S de bajo nivel . Las capas de E / S de nivel superior, como stdio, pueden mantener sus propios búferes separados.
Como función en C , la sync()
llamada normalmente se declara como void sync(void)
en
. La llamada al sistema también está disponible a través de una utilidad de línea de comandos también llamada sincronización , y funciones con nombres similares en otros lenguajes como Perl y Node.js (en el módulo fs).
La llamada al sistema relacionada fsync()
confirma solo los datos almacenados en búfer relacionados con un descriptor de archivo específico . [1] fdatasync()
también está disponible para escribir solo los cambios realizados en los datos del archivo, y no necesariamente los metadatos relacionados con el archivo. [2]
Algunos sistemas Unix ejecutan una especie de demonio de descarga o actualización , que llama a la función de sincronización de forma regular. En algunos sistemas, el demonio cron hace esto, y en Linux fue manejado por el demonio pdflush que fue reemplazado por una nueva implementación y finalmente eliminado del kernel de Linux en 2012. [3] Los búferes también se vacían cuando los sistemas de archivos se desmontan o se vuelven a montar. de solo lectura , [4] por ejemplo antes del apagado del sistema.
Uso de la base de datos
Para proporcionar una durabilidad adecuada , las bases de datos deben utilizar algún tipo de sincronización para asegurarse de que la información escrita haya llegado al almacenamiento no volátil en lugar de simplemente almacenarse en una memoria caché de escritura basada en memoria que se perdería si falla la alimentación. . 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 que escriba una serie de registros, un disco duro rotatorio solo puede confirmar una vez por rotación, lo que genera, en el mejor de los casos, unos pocos cientos de confirmaciones por segundo. [7] Desactivar el requisito de fsync puede, por lo tanto, mejorar en gran medida el rendimiento de la confirmación, pero a costa de introducir potencialmente daños en la base de datos después de un bloqueo.
Las bases de datos también emplean archivos de registro de transacciones (por lo general, mucho más pequeños que los archivos de datos principales) que tienen información sobre cambios recientes, de modo que los cambios pueden rehacerse de manera confiable en caso de falla; entonces los archivos de datos principales se pueden sincronizar con menos frecuencia.
Informe y comprobación de errores
Para evitar cualquier pérdida de datos, se fsync()
deben verificar los valores de retorno de porque al realizar operaciones de E / S que están almacenadas en búfer por la biblioteca o el kernel, es posible que los errores no se informen al momento de usar la write()
llamada al sistema o la fflush()
llamada, ya que los datos pueden no ser informados. escribirse en un almacenamiento no volátil, pero solo en la memoria caché de la página de memoria . En cambio, los errores de escrituras a menudo se informan durante las llamadas al sistema a fsync()
, msync()
o close()
. [8] Antes de 2018, el fsync()
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]
Controversias de rendimiento
Es posible que los discos duros usen de forma predeterminada su propia caché de escritura volátil para almacenar en búfer las escrituras, lo que mejora enormemente el rendimiento al tiempo que presenta la posibilidad de que se pierdan las escrituras. [12] Herramientas como hdparm -F le indicarán al controlador HDD que vacíe el búfer de caché de escritura en la unidad. El impacto en el rendimiento de desactivar el almacenamiento en caché es tan grande que incluso la comunidad normalmente conservadora de FreeBSD rechazó desactivar el almacenamiento en caché de escritura por defecto en FreeBSD 4.3. [13]
En SCSI y en SATA con Native Command Queueing (pero no en ATA simple, incluso con TCQ), el host puede especificar si desea ser notificado de la finalización cuando los datos lleguen a los platos del disco o cuando lleguen al búfer del disco (integrado cache). Suponiendo una implementación de hardware correcta, esta característica permite que se utilice la memoria caché integrada del disco al tiempo que garantiza la semántica correcta para llamadas al sistema como fsync
. [14] Esta función de hardware se llama Forzar acceso a la unidad (FUA) y permite la coherencia con menos gastos generales que vaciar toda la 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 fsync
llamadas al sistema que degradaron su rendimiento; la convocatoria se introdujo para garantizar la integridad de la base de datos SQLite incorporada . [18] El director técnico de la Fundación Linux, Theodore Ts'o, afirma que no hay necesidad de "temer a fsync", y que la verdadera causa de la ralentización de Firefox 3 es el uso excesivo de . [19] Sin embargo, también admite (citando a Mike Shaver ) que "en algunas configuraciones bastante comunes de Linux, especialmente si se usa el sistema de archivos ext3 en el modo" datos = ordenado ", llamar a fsync no solo elimina los datos del archivo al que se llama en, sino en todos los datos almacenados en búfer para ese sistema de archivos ". [20] fsync
Ver también
- Caché de búfer
- Descriptor de archivo
- Sistema de archivos
- inodo
- Supermanzana
Referencias
- ^ especificación fsync
- ^ especificación fdatasync
- ^ http://lwn.net/Articles/508212/
- ^ "montar: desmonta la sincronización de las llamadas para completar las escrituras pendientes" . Stack Exchange de Unix y Linux . Consultado el 2 de mayo de 2021 .
- ^ Vondra, Tomas (2 de febrero de 2019). "PostgreSQL frente a fsync" . Osuosl Org . Archivado desde el original (mp4) el 10 de febrero de 2019 . Consultado el 10 de febrero de 2019 .
- ^ Confiabilidad de PostgreSQL y el registro de escritura anticipada
- ^ Ajuste de la sincronización de PostgreSQL WAL Archivado el 25 de noviembre de 2009 en la Wayback Machine.
- ^ https://lwn.net/Articles/457667/
- ^ https://lwn.net/Articles/752063/
- ^ https://lwn.net/Articles/724307/
- ^ https://patchwork.kernel.org/patch/10358111/
- ^ ¿ Caché de escritura habilitado?
- ^ Manual de FreeBSD - Discos de ajuste
- ^ Marshall Kirk McKusick . "Discos desde la perspectiva de un sistema de archivos - Cola ACM" . Queue.acm.org . Consultado el 11 de enero de 2014 .
- ^ Gregory Smith (2010). PostgreSQL 9.0: Alto rendimiento . Packt Publishing Ltd. pág. 78. ISBN 978-1-84951-031-8.
- ^ http://www.spinics.net/lists/linux-scsi/msg61241.html
- ^ http://lkml.indiana.edu/hypermail/linux/kernel/0702.2/1358.html
- ^ http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/
- ^ http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/
- ^ http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/
enlaces externos
- sync (8): página de manual de Linux .
- http://austingroupbugs.net/view.php?id=672