[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482754
]
Olav Sandstaa commented on DERBY-2020:
--------------------------------------
Suresh and Mike,
Thanks for the comments.
I agree that Derby should not have to do extra work to handle
something that is a JVM bug. Still, since there already is code to
handle this situation I think it is worth to maintain this
functionality given that it does not affect the normal operation of
Derby. And I think Derby running with "rwd" mode for these bug vms
that do not sync is much more likely to result in a non-recoverable
database when running on a disk that has the write cache enabled. With
the write cache enabled on the disk, the data will in most situations
be written to disk even when there is a system crash or power failure
(but with no guarantee). With the data only being written to the file
system cache and no syncing to disk there is a much longer time period
where you do not have the log synced to disk.
I will make a proposal for a fix for how to handle this JVM bug based
on opening a file on the log device (I agree with Suresh that using
the tmp device is not a good idea).
To answer Suresh's second question. Yes, after crash that occurs
while updating a file in "rwd" mode everything that is related to
the content of the file and being able to read the file must be
updated on disk. This should include the length of the file.
> Change file option for syncing log file to disk from rws to rwd
> ---------------------------------------------------------------
>
> Key: DERBY-2020
> URL: https://issues.apache.org/jira/browse/DERBY-2020
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.3.0.0
> Reporter: Olav Sandstaa
> Assigned To: Olav Sandstaa
> Attachments: disk-cache.png, no-disk-cache.png, rwd.diff, rwd.stat
>
>
> For writing the transaction log to disk Derby uses a
> RandomAccessFile. If it is supported by the JVM, the log files are
> opened in "rws" mode making the file system take care of syncing
> writes to disk. "rws" mode will ensure that both the data and the file
> meta-data is updated for every write to the file. On some operating
> systems (e.g. Solaris) this leads to two write operation to the disk
> for every write issued by Derby. This is limiting the throughput of
> update intensive applications. If we could change the file mode to
> "rwd" this could reduce the number of updates to the disk.
> I have run some simple tests where I have changed mode from "rws" to
> "rwd" for the Derby log file. When running a small numbers of
> concurrent client threads the throughput is almost doubled and the
> response time is almost halved. I will attach some graphs that show
> this when running a given number of concurrent "tpc-b" like clients. These
> graphs show the throughput when running with "rws" and "rwd" mode when the
> disk's write cache has been enabled and disabled.
> I am creating this Jira to have a place where we can collect
> information about issues both for and against changing the default
> mode for writing to log files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.