Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <11806807.1173698469525.JavaMail.jira@brutus>
Date: Mon, 12 Mar 2007 04:21:09 -0700 (PDT)
From: "Olav Sandstaa (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2020) Change file option for syncing log
 file to disk from rws to rwd
In-Reply-To: <24595994.1162289536492.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480050 ] 

Olav Sandstaa commented on DERBY-2020:
--------------------------------------

I have discussed this change with someone working on this part of Java
within Sun. The feedback I have received is that the following text in
the JavaDoc for the RandomAccessFile constructor (see
http://java.sun.com/j2se/1.4.2/docs/api/java/io/RandomAccessFile.html):

  "If the file resides on a local storage device then when an
  invocation of a method of this class returns it is guaranteed that
  all changes made to the file by that invocation will have been
  written to that device. This is useful for ensuring that critical
  information is not lost in the event of a system crash. If the file
  does not reside on a local device then no such guarantee is made."

applies to both "rws" and "rwd" mode (as the text says). So with
regards to the content of the file and the possibility to read the
data from the file after a system crash, these two options should have
identical behavior and give identical guarantees. The only
optimizations that "rwd" is allowed to do is to not update meta-data
that are not critical for reading the file data. If data that has been
appended to a file is lost in a crash, the "critical information is
not lost" requirement is broken, and the implementation is
non-conforming to the spec.

This change gives a large performance benefit on some operating
systems. As far as I can see, this should be a safe change to Derby and
I propose this patch being reviewed and committed.

I have run derbyall and the JUnit test suite, and as expected I did
not see any problems. 


> 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.