* Linus Torvalds: > Side note: a lot of systems make "fsync()" pretty expensive too. It's one > of my main disagreements with most log-based filesystems - fsync() can in > theory be fast, but almost always implies flushing the whole log, even if > 99.9% of that log is totally unrelated to the actual file you want to > fsync(). And flushing the whole log might be less expensive than several partial flushes with ordering constraints. If Linux ever gets support for partial log flushes, I suppose you could restore the previous performance by using sync_file_range() with approriate flags (to get the data in flight to disk), followed by a second round of calls to to fsync() (to actually wait for I/O completion). > So fsync() isn't always all that much better than sync(). sync() is potentially a no-op, particularly if some of the targeted files are still open. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
