[
https://issues.apache.org/jira/browse/JCR-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935244#action_12935244
]
Thomas Mueller commented on JCR-2819:
-------------------------------------
As you may know, there was a discussion about how a file system is supposed to
work:
http://www.linux.com/news/software/linux-kernel/4995-filesystems-data-preservation-fsync-and-benchmarks
- so it looks like the most common file systems will not require fsync before
rename.
The patch looks good, but I don't know the performance impact. It would be good
to have some numbers.
In many systems (specially clustered environments) it doesn't make sense to
ensure the data is written to disk, because the system is anyway crash proof.
But even if clustering is not used, in many cases (I would argue in most cases)
it's acceptable to loose the last few seconds of transactions (it's important
that the repository is in a consistent state, but it's not that important that
the very latest committed transaction stored). Therefore, I think it makes
sense to make fsync optional (we can still discuss what the behavior should be).
> FileDataStore not crash safe
> ----------------------------
>
> Key: JCR-2819
> URL: https://issues.apache.org/jira/browse/JCR-2819
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.1.2
> Environment: All
> Reporter: Bernd Eckenfels
> Priority: Minor
> Attachments: FileDataStore.patch
>
>
> The FileDataStore.addRecord() does create a temporary file and rename it to
> the final location. On a crash, this can result in a file which is renamed
> but the content is still empty. This especially happens on systems where data
> in the filesystem is not journaled. You can resolve this problem by calling
> the fdsync() method of the operating system before renaming the file.
> Typically in Java this is done by first flushing all the Java buffers (i.e.
> calling flush() on the highest output stream), and then using the
> getFD().sync(); method on the FileOutputStream.
> Note: this introduced some delay/additional IO load on the system, therefore
> I think it might be best to make it configurable. But I think in some
> environments the additional reliability is badly needed.
> Sample patch without configuration parameter added.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
