En algunos sistemas de archivos, al crear un archivo, es necesario llamar a fsync() no solo en el archivo en sí, sino también en el directorio principal, para que la creación del archivo sea duradera. De lo contrario, la entrada del directorio podría perderse en un desmontaje no limpio; el inodo del archivo quedaría huérfano.
¿Sigue siendo cierto para ext4 o el diario se encarga de eso?
Muchas aplicaciones (por ejemplo, vim, según lo verificado por strace) parecen llamar a fsync solo en el archivo. ¿Es eso seguro?
Actualización: encometer 14ece1028b3ed53ffec1b1213ffc6acaf79ad77cal kernel, ext4 se cambia específicamente para que,con diario deshabilitado, la entrada del directorio principal se fsync() automáticamente cuando se fsync() el archivo en sí. Pero ¿qué pasa con el registro en diario habilitado? ¿Está implícito el directorio fsync(), ya que es parte de la misma transacción que la creación del nuevo inodo?
Respuesta1
Yo diría "depende" en parte, porque se pueden cambiar las opciones de diario de ext4 de modo que se registren archivos completos o solo metadatos, y si estos se confirman inmediatamente o no depende en parte de las configuraciones del hardware.
En el caso de que ext4 esté montado con al menos un registro de metadatos y el subsistema no almacene en caché las escrituras, le sugiero que no necesite sincronizar el directorio.
Sin embargo, desde'ext4 vs fsync' de Larsson:
Cabe señalar que POSIX, e incluso ext4, no ofrecen garantías de que el archivo sobrevivirá a una falla del sistema, incluso si se usa fsync.
No es una respuesta completa, pero la publicación del blog en cuestión detalla los problemas del diario y la pérdida de datos. Si bien no es reciente, creo que todavía representa el estado actual de ext4 y sus comentarios sobre cuándo usar o no fsync tienen mérito.