You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@zookeeper.apache.org by "Dmitrii Kovalkov (Jira)" <ji...@apache.org> on 2021/06/02 11:58:00 UTC
[jira] [Created] (ZOOKEEPER-4311) Fsync errors are ignored in
AtomicFileWritingIdiom
Dmitrii Kovalkov created ZOOKEEPER-4311:
-------------------------------------------
Summary: Fsync errors are ignored in AtomicFileWritingIdiom
Key: ZOOKEEPER-4311
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4311
Project: ZooKeeper
Issue Type: Bug
Components: leaderElection, server
Reporter: Dmitrii Kovalkov
Class AtomicFileOutputStream has a non-trivial logic in its 'close' method. ([code|https://github.com/apache/zookeeper/blob/5c102298f8a160ea996be7b6d6f95189d4ff2f41/zookeeper-server/src/main/java/org/apache/zookeeper/common/AtomicFileOutputStream.java#L76-L106]).
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|https://github.com/apache/zookeeper/blob/5c102298f8a160ea996be7b6d6f95189d4ff2f41/zookeeper-server/src/main/java/org/apache/zookeeper/common/AtomicFileWritingIdiom.java#L87]).
But docs says that IOUtils.closeStream ignores IOException, which can happen during fsync. ([docs|https://hadoop.apache.org/docs/r2.7.3/api/org/apache/hadoop/io/IOUtils.html#closeStream(java.io.Closeable)]). 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)