Si solo le importa ext4 y no ext3, le recomiendo usar fsync en el nuevo archivo antes de cambiar el nombre. El rendimiento de fsync en ext4 parece ser mucho mejor que en ext3 sin los retrasos muy largos. O podría ser el hecho de que la reescritura es el modo predeterminado (al menos en mi sistema Linux).
Si solo le importa que el archivo esté completo y no qué archivo se nombra en el directorio, solo necesita fsync el nuevo archivo. No hay necesidad de sincronizar el directorio también, ya que apuntará al archivo nuevo con sus datos completos o al archivo antiguo.
No
Mire libeatmydata y esta presentación:
Comer mis datos:cómo todo el mundo se equivoca en el archivo IO
http://www.oscon.com/oscon2008/public/schedule/detail/3172
por Stewart Smith de MySql.
En caso de que esté fuera de línea/ya no esté disponible, guardo una copia:
- El vídeo aquí
- Las diapositivas de la presentación (versión en línea de las diapositivas)
De la documentación de ext4:
When mounting an ext4 filesystem, the following option are accepted:
(*) == default
auto_da_alloc(*) Many broken applications don't use fsync() when
noauto_da_alloc replacing existing files via patterns such as
fd = open("foo.new")/write(fd,..)/close(fd)/
rename("foo.new", "foo"), or worse yet,
fd = open("foo", O_TRUNC)/write(fd,..)/close(fd).
If auto_da_alloc is enabled, ext4 will detect
the replace-via-rename and replace-via-truncate
patterns and force that any delayed allocation
blocks are allocated such that at the next
journal commit, in the default data=ordered
mode, the data blocks of the new file are forced
to disk before the rename() operation is
committed. This provides roughly the same level
of guarantees as ext3, and avoids the
"zero-length" problem that can happen when a
system crashes before the delayed allocation
blocks are forced to disk.
A juzgar por la frase "aplicaciones rotas", definitivamente se considera una mala práctica por parte de los desarrolladores de ext4, pero en la práctica es un enfoque tan ampliamente utilizado que fue parcheado en ext4 mismo.
Entonces, si su uso se ajusta al patrón, debería estar seguro.
Si no es así, le sugiero que investigue más en lugar de insertar fsync aquí y allá sólo para estar seguro. Puede que no sea una buena idea desde fsync puede ser un gran golpe de rendimiento en ext3 (lectura).
Por otro lado, vaciar antes de cambiar el nombre es la forma correcta de realizar el reemplazo en sistemas de archivos que no están registrados en diario. Tal vez por eso ext4 al principio esperaba este comportamiento de los programas, el auto_da_alloc La opción se agregó más tarde como una solución. Además, este parche ext3 para el modo de reescritura (sin registro en diario) intenta ayudar a los programas descuidados mediante el vaciado asincrónico al cambiar el nombre para reducir la posibilidad de pérdida de datos.
Puede leer más sobre el problema de ext4 aquí.