[
https://issues.apache.org/jira/browse/ZOOKEEPER-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14086132#comment-14086132
]
Flavio Junqueira commented on ZOOKEEPER-2003:
---------------------------------------------
I suppose this is because we force to disk with the metadata option set to
false (FileTxnLog.commit):
{noformat}
log.getChannel().force(false);
{noformat}
Are you suggesting that we force to disk with the metadata option set to true
upon creating a new file? We do flush the BufferedOutputStream associated to
the FileOutputStream, but that only flushes the buffer of BOS to FOS, my
understanding of the documentation is that it doesn't induce a force.
> Missing fsync() on the logs parent directory
> --------------------------------------------
>
> Key: ZOOKEEPER-2003
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2003
> Project: ZooKeeper
> Issue Type: Bug
> Affects Versions: 3.4.6
> Reporter: Samer Al-Kiswany
>
> After studying the steps ZooKeeper takes to update the logs we found the
> following bug. The bug may not manifest in the current file system
> implementations, but it violates the POSIX recommendations and may be an
> issue in some file systems.
> Looking at the strace of zookeeper we see the following:
> mkdir(v)
> create(v/log)
> append(v/log)
> trunk(v/log)
> write(v/log)
> fdatasync(v/log)
> Although the data is fdatasynced to the log, the parent directory was never
> fsynced, consequently in case of a crash, the parent directory or the log
> file may be lost, as the parent directory and file metadata were never
> persisted on disk.
> To be safe, both the log directory, and parent directory of the log directory
> should be fsynced as well.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
