git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: reducing prune sync()s

From
FWFlorian Weimer <fw@deneb.enyo.de>
Date
May 30, 2008, 20:07 UTC
Message-ID
<87iqwvo8sp.fsf@mid.deneb.enyo.de>
In-Reply-To
<alpine.LFD.1.10.0805291727490.3141@woody.linux-foundation.org>
* Linus Torvalds:
Show 5 quoted lines
> 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.

Previous: Frank Ch. EiglerNext: David Dillow
Message 5 of 15 in “reducing prune sync()s”
  1. Frank Ch. EiglerMay 29, 2008
  2. Linus TorvaldsMay 30, 2008
  3. Linus TorvaldsMay 30, 2008
  4. Frank Ch. EiglerMay 30, 2008
  5. Florian WeimerMay 30, 2008
  6. David DillowMay 30, 2008
  7. Linus TorvaldsMay 30, 2008
  8. Linus TorvaldsMay 30, 2008
  9. Frank Ch. EiglerMay 30, 2008
  10. Linus TorvaldsMay 30, 2008
  11. 1/2 Make pack creation always fsync() the resultLinus Torvalds, May 30, 2008
  12. 2/2 Remove now unnecessary 'sync()' callsLinus Torvalds, May 30, 2008
  13. Nicolas PitreMay 30, 2008
  14. Frank Ch. EiglerMay 31, 2008
  15. Linus TorvaldsJun 2, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.