[
https://issues.apache.org/jira/browse/CASSANDRA-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114495#comment-13114495
]
Peter Schuller commented on CASSANDRA-3248:
-------------------------------------------
@zhu Your initial benchmark in the bug submission, on what file system was that?
I'm guessing a journaled file system that only journals meta data. I was going
to suggest that I'd expect both the meta data and the slight bit of data append
to end up in the journal so that the difference should be negligible, but then
realized this won't be the case for metadata-only journaling.
I agree about the documentation phrasing w.r.t. subsequent retrieval, but also
agree that it's dangerous to therefor assume it's safe in practice.
Maybe a configuration option defaulting to false, allowing people who really
know that it's safe on their systems and are affected by it to turn it on?
Given that it only affects a flag passed to force(), the maintenance overhead
should be very small.
> CommitLog writer should call fdatasync instead of fsync
> -------------------------------------------------------
>
> Key: CASSANDRA-3248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3248
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.6.13, 0.7.9, 0.8.6, 1.0.0, 1.1
> Environment: Linux
> Reporter: Zhu Han
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> CommitLogSegment uses SequentialWriter to flush the buffered data to log
> device. It depends on FileDescriptor#sync() which invokes fsync() as it force
> the file attributes to disk.
> However, at least on Linux, fdatasync() is good enough for commit log flush:
> bq. fdatasync() is similar to fsync(), but does not flush modified metadata
> unless that metadata is needed in order to allow a subsequent data retrieval
> to be correctly handled. For example, changes to st_atime or st_mtime
> (respectively, time of last access and time of last modification; see
> stat(2)) do not require flushing because they are not necessary for a
> subsequent data read to be handled correctly. On the other hand, a change to
> the file size (st_size, as made by say ftruncate(2)), would require a
> metadata flush.
> File size is synced to disk by fdatasync() either. Although the commit log
> recovery logic sorts the commit log segements on their modify timestamp, it
> can be removed safely, IMHO.
> I checked the native code of JRE 6. On Linux and Solaris,
> FileChannel#force(false) invokes fdatasync(). On windows, the false flag does
> not have any impact.
> On my log device (commodity SATA HDD, write cache disabled), there is large
> performance gap between fsync() and fdatasync():
> {quote}
> $sysbench --test=fileio --num-threads=1 --file-num=1 --file-total-size=10G
> --file-fsync-all=on --file-fsync-mode={color:red}fdatasync{color}
> --file-test-mode=seqwr --max-time=600 --file-block-size=2K --max-requests=0
> run
> {color:blue}54.90{color} Requests/sec executed
> per-request statistics:
> min: 8.29ms
> avg: 18.18ms
> max: 108.36ms
> approx. 95 percentile: 25.02ms
> $ sysbench --test=fileio --num-threads=1 --file-num=1 --file-total-size=10G
> --file-fsync-all=on --file-fsync-mode={color:red}fsync{color}
> --file-test-mode=seqwr --max-time=600 --file-block-size=2K --max-requests=0
> run
> {color:blue}28.08{color} Requests/sec executed
> per-request statistics:
> min: 33.28ms
> avg: 35.61ms
> max: 911.87ms
> approx. 95 percentile: 41.69ms
> {quote}
> I do think this is a very critical performance improvement.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
