Chris Turner wrote:
> 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.

No, you're not wrong.

The question here is what is the "transaction" that needs to be in a known
state. Anything reading this file will see the cached data, so no
inconsistency. also afaik, there aren't any other files which depend on this
file, but which may be written out first. there's no requirement for this data
to be written out in a particular order with respect to other data.

The window in which the data is not written you refer to also exists before
(and even during) the fsync call. That data should also be written cleanly
before shutdown.

fwiw other people have seen other symptoms of the system failing to fully
flush write buffers before shutdown. some aspect of vfs_sync/shutdown is not
trying "hard enough" to get the job done.

Reply via email to