Reputation: 8505
When write call returns, the data is copied onto some page managed by kernel. That page can contain writes from multiple process. So, when one of the applications issues fsync call, will this result in flushing the whole page, which means flushing other applications data also, but the cost would be incurred by the process which calls fsync. Is this correct?
Upvotes: 12
Views: 9017
Reputation: 16379
The man page states
flushes to disk any data written to this file
which includes file metadata.
I think you are confusing this with sync
which does write all the dirty pages from the entire cache to disk. Dirty page == changed data. And the process has to wait for all of that to complete. If by cost you mean wait, then yes this one incurs cost. Kernel time is added to the process system time resource usage.
fsync also incurs cost, plus a much smaller amount of kernel time than sync(usually).
Upvotes: 2
Reputation: 54325
fsync
operates on a single file. It will flush all changes made to that file. If multiple processes are writing into a single file the process that made the fsync
call will be paused until all the changes are written to disk.
This is more complicated when some journaling filesystems come into play. For example, ext3 and ext4 (to a lesser extent) with the "ordered" mode are required to flush all the changes to all of the files ahead of the fsync file in the journal.
That means that if programs have been writing to a large database or a large log file or a video file and you then fsync
a two-line configuration file, your fsync
must wait for all those megabytes of data to be written before it can return.
This is why I run my ext4 in "writeback" mode, which can have some unpleasant consequences after a crash such as files of the correct size but filled with zeroes. But in normal operation "writeback" is so much faster that I feel the tradeoff is worth it.
Upvotes: 9