You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR fixes a problem with the winlogbeat registry on windows: #2434
Both winglogbeat and filebeat write registry files, by first creating a new file and then replacing the old file using move(Rename).
In winlogbeat it is solved by enabling direct write through when writing the registry file (O_DIRECT + O_SYNC?).
The main issue is, a Close operation on a file does not necessarily imply the file is flushed to disk in full. This is no windows only issue. Instead of relying on direct write through, a better sequence for filebeat/winlogbeat registry updates would be: create tmp file -> serialize registry -> fsync tmp file -> close tmp file -> move tmp file into correct location -> run fsync on new parent directory.
Filebeat already uses O_SYNC, but I'm not sure about the current state of O_SYNC on Linux. In the past it has been known O_SYNC actually behaving like O_DSYNC (wonder if this is solved by now).
The text was updated successfully, but these errors were encountered:
This PR fixes a problem with the winlogbeat registry on windows: #2434
Both winglogbeat and filebeat write registry files, by first creating a new file and then replacing the old file using move(Rename).
In winlogbeat it is solved by enabling direct write through when writing the registry file (O_DIRECT + O_SYNC?).
The main issue is, a
Close
operation on a file does not necessarily imply the file is flushed to disk in full. This is no windows only issue. Instead of relying on direct write through, a better sequence for filebeat/winlogbeat registry updates would be: create tmp file -> serialize registry -> fsync tmp file -> close tmp file -> move tmp file into correct location -> run fsync on new parent directory.Filebeat already uses O_SYNC, but I'm not sure about the current state of O_SYNC on Linux. In the past it has been known O_SYNC actually behaving like O_DSYNC (wonder if this is solved by now).
The text was updated successfully, but these errors were encountered: