Thread (1 message) 1 message, 1 author, 2016-06-15

Re: reducing prune sync()s

From: Florian Weimer <hidden>
Date: 2016-06-15 22:44:39

* 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help