Rik van Riel wrote: > The ext4 automatic-fsync-on-rename discussion has shown that > many applications simply Do It Wrong when it comes to rewriting > configuration files. I got the impression ext4 has automatic-fsync-on-rename-only-if-the-old-file-exists, which is a bit less reliable. By the way, the kernel has some generic support for O_SYNC and O_DSYNC, and generic MS_SYNC mount option. So I guess it could also have generic support for mount options "sync_on_rename" and "sync_on_close", instead of only doing it with ext4. For example, this came up recently on the linux-mtd list which deals with flash filesystems. The ext4-like behaviour is being considerd in a flash filesystem. So if it's that important, maybe it would be even better to make it a generic VFS mount option for all filesystems. > Some of the common failures are: > - program overwrites the old config file > - program writes a new file, but forgets to fsync before rename > - program writes the new file in /tmp, so the rename fails on > some systems > - program writes a new file and fsyncs, but forgets to give the > new file the same file ownership, permission and/or extended > attributes as the old file It's also really hard to do those things from shell scripts, so they are almost never done there. > Glibc has the advantage of it not being in the kernel, but > implementing it in-kernel might give us the opportunity for > performance enhancements, like reducing step (5) to merely > enforcing ordering between filesystem operations, instead > of requiring an fsync. I think the performance enhancement from order-without-sync might be useful, I'm not sure, but if so not just for this operation, which is still quite specialised. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
