Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <23104915.1175622032381.JavaMail.jira@brutus>
Date: Tue, 3 Apr 2007 10:40:32 -0700 (PDT)
From: "Suresh Thalamati (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_12486434 ] 

Suresh Thalamati commented on DERBY-2020:
-----------------------------------------

Thanks  for working on this issue Olav. your latest patch jvmsyncbug_v2.diff
looks good. couple of minor comments:

1) One thing that puzzled me is why are you creating a new 
file "rwtest.tmp" ? why can not the test be done on the current log file 
itself,  by opening the log file in "rws" mode and then closing, before
it is opened in the  appropriate mode. That way you can avoid a creating a
new file and deleting it. 

2) 
And Also, there are these weird read only db state scenarios. For example 
if you attempt to create a file when the db is made read readonly by putting it
in a jar, derby is ok as long as there are no transactions pending. If there 
any pending transaction we may not catch it any more, because jvmsyncError() method 
attempting to create a "rwtest.tmp" file very early, it may fail immediately on
log factory boot and decide all is well to treat the database as READONLY. But
it will be a inconsistent one. 

I think derby tests suites  has a readonly test, but i am not sure it covers pending
transaction error case. 


> 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, jvmsyncbug.diff, jvmsyncbug.stat, jvmsyncbug_v2.diff, jvmsyncbug_v2.stat, 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.