jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2819) FileDataStore not crash safe
Date Wed, 24 Nov 2010 08:11:14 GMT

    [ 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

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.

View raw message