On 11/12/15 14:10, Ted Unangst wrote:
Chris Turner wrote:
>>>
The attached patch calls fsync(2) on related FD's in the login(3)
routines, which corrected the problem on my test machine,
and imho might be a good idea in general.
AFAIK it should not be necessary to call fsync() before close(). Closing a
file should flush all its data. The patch either does nothing, or masks a much
more serious somewhere else. (The latter is a distinct possibility, but we
can't go adding fsync to hundreds of file operations throughout the tree.)
Will defer -
To be clear however, in this case I'm strictly referring to the (brief)
time window between data being flushed from the process and that data then
being sync'ed to disk by the system -
E.g., as related to fsync(2):
"
fsync() and fdatasync() should be used by programs that require a file to
be in a known state, for example, in building a simple transaction
facility.
"
obviously there's still the case of physical disk caches, etc.
I realize fsync is not done everywhere on file close, and likely rightfully
so in many/most cases - my thinking was that here specifically might be a
good place given the type of (sensitive, non-reproducable) data being stored.
Again, deferring, but, thought i'd clarify a bit more of my thinking
in case it might be beneficial to the discussion.
Cheers,
- Chris
