[ZOOKEEPER-4311] Fsync errors are ignored in AtomicFileWritingIdiom

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 3.8.0
• Component/s: leaderElection, server
• Labels: pull-request-available
• Assignee: Unassigned
• Reporter: Dmitrii Kovalkov
• Created: 02/Jun/21 11:57
• Updated: 28/Jun/21 11:36
• Resolved: 21/Jun/21 11:16

Description

Class AtomicFileOutputStream has a non-trivial logic in its 'close' method. (code).
It ensures that data is persistently stored on the disk via 'flush' and 'fsync' to .tmp file, then tries to rename the file. In case of any errors, .tmp file is deleted and exception is thrown.

AtomicFileWritingIdiom, which is based on AtomicFileOutputStream, only calls 'flush' explicitly. 'close' method is called via IOUtils.closeStream (code).
But docs says that IOUtils.closeStream ignores IOException, which can happen during fsync. (docs). As a result, in case of fsync errors, .tmp file is deleted, main file is not updated, but zookeeper ignores an exception and assumes that everything is ok.

AtomicFileWritingIdiom is used in leader election to store 'currentEpoch' and 'acceptedEpoch' files. This bug theoreticly can lead to electing two leaders in one epoch in case of disk failures.

 

Issue Links

• links to: GitHub Pull Request #1706