You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Joseph Grace <oc...@serv.net> on 2004/09/04 23:38:19 UTC
java1.4.2 "rws" mode - log write performance - OSX numbers
Here are some stats from OSX
1.5GHz PowerBook
5400 rpm h/d (internal), 80GB@87% full
HFS+ file system
FYI, notably some tests can vary widely in speed. For instance, they
can speed considerably ( >50% faster than some prior runs) if the test
is run again immediately. There were some other variations (not always
speedups) on the order of 10% on some tests. Here are some interesting
"rws" and "rwd" results distilled from three varied runs:
04. Testing growing file using RandomAccessFile "rws": Writes per
second: 9132.42 writes/s
04. Testing growing file using RandomAccessFile "rws": Writes per
second: 8703.22 writes/s
04. Testing growing file using RandomAccessFile "rws": Writes per
second: 12853.47 writes/s
05. Testing preallocated file using RandomAccessFile "rws": Failed
with exception: java.io.FileNotFoundException: (File exists)
05. Testing preallocated file using RandomAccessFile "rws": Failed
with exception: java.io.FileNotFoundException: (File exists)
05. Testing preallocated file using RandomAccessFile "rws": Failed
with exception: java.io.FileNotFoundException: (File exists)
06. Testing growing file using RandomAccessFile "rwd": Writes per
second: 6693.44 writes/s
06. Testing growing file using RandomAccessFile "rwd": Writes per
second: 11198.208 writes/s
06. Testing growing file using RandomAccessFile "rwd": Writes per
second: 14836.795 writes/s
07. Testing preallocated file using RandomAccessFile "rwd": Writes per
second: 9523.81 writes/s
07. Testing preallocated file using RandomAccessFile "rwd": Writes per
second: 10438.413 writes/s
07. Testing preallocated file using RandomAccessFile "rwd": Writes per
second: 19801.98 writes/s
12. Testing growing file using direct buffer + FileChannel "rws":
Writes per second: 9523.81 writes/s
12. Testing growing file using direct buffer + FileChannel "rws":
Writes per second: 10626.993 writes/s
12. Testing growing file using direct buffer + FileChannel "rws":
Writes per second: 14727.541 writes/s
13. Testing preallocated file using direct buffer + FileChannel "rws":
Failed with exception: java.io.FileNotFoundException: (File exists)
13. Testing preallocated file using direct buffer + FileChannel "rws":
Failed with exception: java.io.FileNotFoundException: (File exists)
13. Testing preallocated file using direct buffer + FileChannel "rws":
Failed with exception: java.io.FileNotFoundException: (File exists)
14. Testing growing file using direct buffer + FileChannel "rwd":
Writes per second: 6035.003 writes/s
14. Testing growing file using direct buffer + FileChannel "rwd":
Writes per second: 9950.249 writes/s
14. Testing growing file using direct buffer + FileChannel "rwd":
Writes per second: 8424.6 writes/s
15. Testing preallocated file using direct buffer + FileChannel "rwd":
Writes per second: 8568.98 writes/s
15. Testing preallocated file using direct buffer + FileChannel "rwd":
Writes per second: 10559.662 writes/s
15. Testing preallocated file using direct buffer + FileChannel "rwd":
Writes per second: 13333.333 writes/s
NB: "rws" fails with an unrecoverable error in tests #5 and #13, so I
vote -1 on using "preallocated+rws" as a derby write strategy (at least
for now until the "preallocated+rws" file open failure root cause is
identified (e.g., whether this exception is valid or somehow in
violation of a specification).
The first run was the first ever run of the program on the system. The
second was the third run after a reboot (i.e., reboot, run, run, do
plenty of other work, then result run), and the final run was
immediately following the second run (i.e., a fast run). I'm not sure
which of these is most representative, but the variance is at least
interesting.
The full results from the second (middling) run above are appended.
= Joe =
---------------------------------------------
1. System info:
---------------------------------------------
OS Platform: Mac OS X/ppc/10.3.5
Java spec: Java Platform API Specification version 1.4 from Sun
Microsystems Inc.
Java VM: Java HotSpot(TM) Client VM version 1.4.2-38 from "Apple
Computer, Inc."
Java home:
/System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Home
Test file: /Users/occam/dev/java/derby/test.bin
Test file exists, deleting...
---------------------------------------------------------------------
2. Testing growing file using RandomAccessFile "rw" + .getFD().sync()
---------------------------------------------------------------------
Chunk size: 4228 bytes
Count: 10000
Total time: 10527 ms
Writes per second: 949.938 writes/s
Time per chunk: 1.053 ms
Write bandwidth: 3.0MB/s
------------------------------------------------------------------------
---
3. Testing preallocated file using RandomAccessFile "rw" +
.getFD().sync()
------------------------------------------------------------------------
---
Chunk size: 4228 bytes
Count: 10000
Total time: 10088 ms
Writes per second: 991.277 writes/s
Time per chunk: 1.009 ms
Write bandwidth: 3.0MB/s
---------------------------------------------------------------------
4. Testing growing file using RandomAccessFile "rws"
---------------------------------------------------------------------
Chunk size: 4228 bytes
Count: 10000
Total time: 1149 ms
Writes per second: 8703.22 writes/s
Time per chunk: 0.115 ms
Write bandwidth: 35.0MB/s
---------------------------------------------------------------------
5. Testing preallocated file using RandomAccessFile "rws"
---------------------------------------------------------------------
Failed with exception: java.io.FileNotFoundException:
/Users/occam/dev/java/derby/test.bin (File exists)
---------------------------------------------------------------------
6. Testing growing file using RandomAccessFile "rwd"
---------------------------------------------------------------------
Chunk size: 4228 bytes
Count: 10000
Total time: 893 ms
Writes per second: 11198.208 writes/s
Time per chunk: 0.089 ms
Write bandwidth: 45.0MB/s
---------------------------------------------------------------------
7. Testing preallocated file using RandomAccessFile "rwd"
---------------------------------------------------------------------
Chunk size: 4228 bytes
Count: 10000
Total time: 958 ms
Writes per second: 10438.413 writes/s
Time per chunk: 0.096 ms
Write bandwidth: 42.0MB/s
------------------------------------------------------------------------
------
8. Testing growing file using direct buffer + FileChannel "rw" +
force(true)
------------------------------------------------------------------------
------
Chunk size: 4228 bytes
Count: 10000
Total time: 10032 ms
Writes per second: 996.81 writes/s
Time per chunk: 1.003 ms
Write bandwidth: 4.0MB/s
------------------------------------------------------------------------
-----------
9. Testing preallocated file using direct buffer + FileChannel "rw" +
force(true)
------------------------------------------------------------------------
-----------
Chunk size: 4228 bytes
Count: 10000
Total time: 10062 ms
Writes per second: 993.838 writes/s
Time per chunk: 1.006 ms
Write bandwidth: 4.0MB/s
------------------------------------------------------------------------
------
10. Testing growing file using direct buffer + FileChannel "rw" +
force(false)
------------------------------------------------------------------------
------
Chunk size: 4228 bytes
Count: 10000
Total time: 10241 ms
Writes per second: 976.467 writes/s
Time per chunk: 1.024 ms
Write bandwidth: 3.0MB/s
------------------------------------------------------------------------
------
11. Testing preallocated file using direct buffer + FileChannel "rw" +
force(false)
------------------------------------------------------------------------
------
Chunk size: 4228 bytes
Count: 10000
Total time: 10226 ms
Writes per second: 977.899 writes/s
Time per chunk: 1.023 ms
Write bandwidth: 3.0MB/s
------------------------------------------------------------------------
------
12. Testing growing file using direct buffer + FileChannel "rws"
------------------------------------------------------------------------
------
Chunk size: 4228 bytes
Count: 10000
Total time: 941 ms
Writes per second: 10626.993 writes/s
Time per chunk: 0.094 ms
Write bandwidth: 42.0MB/s
------------------------------------------------------------------------
------
13. Testing preallocated file using direct buffer + FileChannel "rws"
------------------------------------------------------------------------
------
Failed with exception: java.io.FileNotFoundException:
/Users/occam/dev/java/derby/test.bin (File exists)
------------------------------------------------------------------------
------
14. Testing growing file using direct buffer + FileChannel "rwd"
------------------------------------------------------------------------
------
Chunk size: 4228 bytes
Count: 10000
Total time: 1005 ms
Writes per second: 9950.249 writes/s
Time per chunk: 0.101 ms
Write bandwidth: 40.0MB/s
------------------------------------------------------------------------
------
15. Testing preallocated file using direct buffer + FileChannel "rwd"
------------------------------------------------------------------------
------
Chunk size: 4228 bytes
Count: 10000
Total time: 947 ms
Writes per second: 10559.662 writes/s
Time per chunk: 0.095 ms
Write bandwidth: 42.0MB/s
Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Posted by Suresh Thalamati <ts...@Source-Zone.org>.
Hi Joe,
Does Mac OS has concept of write cache enabling ? Numbers below
are with write cache enabled/disabled ?
-suresht
Joseph Grace wrote:
> Here are some stats from OSX
>
> 1.5GHz PowerBook
> 5400 rpm h/d (internal), 80GB@87% full
> HFS+ file system
>
> FYI, notably some tests can vary widely in speed. For instance, they
> can speed considerably ( >50% faster than some prior runs) if the
> test is run again immediately. There were some other variations (not
> always speedups) on the order of 10% on some tests. Here are some
> interesting "rws" and "rwd" results distilled from three varied runs:
>
> 04. Testing growing file using RandomAccessFile "rws": Writes per
> second: 9132.42 writes/s
> 04. Testing growing file using RandomAccessFile "rws": Writes per
> second: 8703.22 writes/s
> 04. Testing growing file using RandomAccessFile "rws": Writes per
> second: 12853.47 writes/s
> 05. Testing preallocated file using RandomAccessFile "rws": Failed
> with exception: java.io.FileNotFoundException: (File exists)
> 05. Testing preallocated file using RandomAccessFile "rws": Failed
> with exception: java.io.FileNotFoundException: (File exists)
> 05. Testing preallocated file using RandomAccessFile "rws": Failed
> with exception: java.io.FileNotFoundException: (File exists)
> 06. Testing growing file using RandomAccessFile "rwd": Writes per
> second: 6693.44 writes/s
> 06. Testing growing file using RandomAccessFile "rwd": Writes per
> second: 11198.208 writes/s
> 06. Testing growing file using RandomAccessFile "rwd": Writes per
> second: 14836.795 writes/s
> 07. Testing preallocated file using RandomAccessFile "rwd": Writes
> per second: 9523.81 writes/s
> 07. Testing preallocated file using RandomAccessFile "rwd": Writes
> per second: 10438.413 writes/s
> 07. Testing preallocated file using RandomAccessFile "rwd": Writes
> per second: 19801.98 writes/s
> 12. Testing growing file using direct buffer + FileChannel "rws":
> Writes per second: 9523.81 writes/s
> 12. Testing growing file using direct buffer + FileChannel "rws":
> Writes per second: 10626.993 writes/s
> 12. Testing growing file using direct buffer + FileChannel "rws":
> Writes per second: 14727.541 writes/s
> 13. Testing preallocated file using direct buffer + FileChannel
> "rws": Failed with exception: java.io.FileNotFoundException: (File
> exists)
> 13. Testing preallocated file using direct buffer + FileChannel
> "rws": Failed with exception: java.io.FileNotFoundException: (File
> exists)
> 13. Testing preallocated file using direct buffer + FileChannel
> "rws": Failed with exception: java.io.FileNotFoundException: (File
> exists)
> 14. Testing growing file using direct buffer + FileChannel "rwd":
> Writes per second: 6035.003 writes/s
> 14. Testing growing file using direct buffer + FileChannel "rwd":
> Writes per second: 9950.249 writes/s
> 14. Testing growing file using direct buffer + FileChannel "rwd":
> Writes per second: 8424.6 writes/s
> 15. Testing preallocated file using direct buffer + FileChannel
> "rwd": Writes per second: 8568.98 writes/s
> 15. Testing preallocated file using direct buffer + FileChannel
> "rwd": Writes per second: 10559.662 writes/s
> 15. Testing preallocated file using direct buffer + FileChannel
> "rwd": Writes per second: 13333.333 writes/s
>
> NB: "rws" fails with an unrecoverable error in tests #5 and #13, so
> I vote -1 on using "preallocated+rws" as a derby write strategy (at
> least for now until the "preallocated+rws" file open failure root
> cause is identified (e.g., whether this exception is valid or somehow
> in violation of a specification).
>
> The first run was the first ever run of the program on the system.
> The second was the third run after a reboot (i.e., reboot, run, run,
> do plenty of other work, then result run), and the final run was
> immediately following the second run (i.e., a fast run). I'm not
> sure which of these is most representative, but the variance is at
> least interesting.
>
> The full results from the second (middling) run above are appended.
>
> = Joe =
>
>
> ---------------------------------------------
> 1. System info:
> ---------------------------------------------
>
> OS Platform: Mac OS X/ppc/10.3.5
> Java spec: Java Platform API Specification version 1.4 from Sun
> Microsystems Inc.
> Java VM: Java HotSpot(TM) Client VM version 1.4.2-38 from "Apple
> Computer, Inc."
> Java home:
> /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Home
> Test file: /Users/occam/dev/java/derby/test.bin
>
> Test file exists, deleting...
>
> ---------------------------------------------------------------------
> 2. Testing growing file using RandomAccessFile "rw" + .getFD().sync()
> ---------------------------------------------------------------------
> Chunk size: 4228 bytes
> Count: 10000
> Total time: 10527 ms
> Writes per second: 949.938 writes/s
> Time per chunk: 1.053 ms
> Write bandwidth: 3.0MB/s
>
> ------------------------------------------------------------------------
> ---
> 3. Testing preallocated file using RandomAccessFile "rw" +
> .getFD().sync()
> ------------------------------------------------------------------------
> ---
> Chunk size: 4228 bytes
> Count: 10000
> Total time: 10088 ms
> Writes per second: 991.277 writes/s
> Time per chunk: 1.009 ms
> Write bandwidth: 3.0MB/s
>
> ---------------------------------------------------------------------
> 4. Testing growing file using RandomAccessFile "rws"
> ---------------------------------------------------------------------
> Chunk size: 4228 bytes
> Count: 10000
> Total time: 1149 ms
> Writes per second: 8703.22 writes/s
> Time per chunk: 0.115 ms
> Write bandwidth: 35.0MB/s
>
> ---------------------------------------------------------------------
> 5. Testing preallocated file using RandomAccessFile "rws"
> ---------------------------------------------------------------------
>
> Failed with exception: java.io.FileNotFoundException:
> /Users/occam/dev/java/derby/test.bin (File exists)
>
>
> ---------------------------------------------------------------------
> 6. Testing growing file using RandomAccessFile "rwd"
> ---------------------------------------------------------------------
> Chunk size: 4228 bytes
> Count: 10000
> Total time: 893 ms
> Writes per second: 11198.208 writes/s
> Time per chunk: 0.089 ms
> Write bandwidth: 45.0MB/s
>
> ---------------------------------------------------------------------
> 7. Testing preallocated file using RandomAccessFile "rwd"
> ---------------------------------------------------------------------
> Chunk size: 4228 bytes
> Count: 10000
> Total time: 958 ms
> Writes per second: 10438.413 writes/s
> Time per chunk: 0.096 ms
> Write bandwidth: 42.0MB/s
>
> ------------------------------------------------------------------------
> ------
> 8. Testing growing file using direct buffer + FileChannel "rw" +
> force(true)
> ------------------------------------------------------------------------
> ------
> Chunk size: 4228 bytes
> Count: 10000
> Total time: 10032 ms
> Writes per second: 996.81 writes/s
> Time per chunk: 1.003 ms
> Write bandwidth: 4.0MB/s
>
> ------------------------------------------------------------------------
> -----------
> 9. Testing preallocated file using direct buffer + FileChannel "rw" +
> force(true)
> ------------------------------------------------------------------------
> -----------
> Chunk size: 4228 bytes
> Count: 10000
> Total time: 10062 ms
> Writes per second: 993.838 writes/s
> Time per chunk: 1.006 ms
> Write bandwidth: 4.0MB/s
>
> ------------------------------------------------------------------------
> ------
> 10. Testing growing file using direct buffer + FileChannel "rw" +
> force(false)
> ------------------------------------------------------------------------
> ------
> Chunk size: 4228 bytes
> Count: 10000
> Total time: 10241 ms
> Writes per second: 976.467 writes/s
> Time per chunk: 1.024 ms
> Write bandwidth: 3.0MB/s
>
> ------------------------------------------------------------------------
> ------
> 11. Testing preallocated file using direct buffer + FileChannel "rw"
> + force(false)
> ------------------------------------------------------------------------
> ------
> Chunk size: 4228 bytes
> Count: 10000
> Total time: 10226 ms
> Writes per second: 977.899 writes/s
> Time per chunk: 1.023 ms
> Write bandwidth: 3.0MB/s
>
> ------------------------------------------------------------------------
> ------
> 12. Testing growing file using direct buffer + FileChannel "rws"
> ------------------------------------------------------------------------
> ------
> Chunk size: 4228 bytes
> Count: 10000
> Total time: 941 ms
> Writes per second: 10626.993 writes/s
> Time per chunk: 0.094 ms
> Write bandwidth: 42.0MB/s
>
> ------------------------------------------------------------------------
> ------
> 13. Testing preallocated file using direct buffer + FileChannel "rws"
> ------------------------------------------------------------------------
> ------
>
> Failed with exception: java.io.FileNotFoundException:
> /Users/occam/dev/java/derby/test.bin (File exists)
>
>
> ------------------------------------------------------------------------
> ------
> 14. Testing growing file using direct buffer + FileChannel "rwd"
> ------------------------------------------------------------------------
> ------
> Chunk size: 4228 bytes
> Count: 10000
> Total time: 1005 ms
> Writes per second: 9950.249 writes/s
> Time per chunk: 0.101 ms
> Write bandwidth: 40.0MB/s
>
> ------------------------------------------------------------------------
> ------
> 15. Testing preallocated file using direct buffer + FileChannel "rwd"
> ------------------------------------------------------------------------
> ------
> Chunk size: 4228 bytes
> Count: 10000
> Total time: 947 ms
> Writes per second: 10559.662 writes/s
> Time per chunk: 0.095 ms
> Write bandwidth: 42.0MB/s
>
Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Posted by Suresh Thalamati <ts...@Source-Zone.org>.
Joseph Grace wrote:
> Suresh:
>
>> Does Mac OS has concept of write cache enabling ? Numbers below
>> are with write cache enabled/disabled ?
>
>
> Yes, OSX has write cache enabling. Presumably it's on by default
> (though I admit to not knowing how to confirm that), so my numbers
> include it. That's why I ran the test under a variety of
> circumstances. Benchmarks are hard, and the numbers vary a lot, so I
> flagged the variance. I'm not sure what all the factors are, but I
> believe your (implied) suspicion that cache'ing is one such factor.
>
> = Joe =
>
Yes, trying to find out the write cache factor in "rws"/"rwd"
performance numbers. What I observerd is on Win2k i
when write cache is enabled "rws" mode does not seem to sync
immediately to the disk unlike FileDescriptor.sync(); I think this
is ok because user has chosen the write cache enabling option. When
write cache is disabled on windows the "rws" mode
write does seem to perform the sync.(Note: On JDK141 sycn does not
happen this case also).
I don't have much knoweledge of jvm internals , but if the expected
behaviour jvm on MAC OS is similar
to Windows, write performance numbers in "rws/rwd" mode won't be
accurate when write cache is enabled.
I also don't know how to disable the write cache on Mac. Can't really
say "rws" does not sync for sure on Mac
unless the write cache is disabled.
-suresht
Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Posted by Joseph Grace <oc...@serv.net>.
Suresh:
> Does Mac OS has concept of write cache enabling ? Numbers below
> are with write cache enabled/disabled ?
Yes, OSX has write cache enabling. Presumably it's on by default
(though I admit to not knowing how to confirm that), so my numbers
include it. That's why I ran the test under a variety of
circumstances. Benchmarks are hard, and the numbers vary a lot, so I
flagged the variance. I'm not sure what all the factors are, but I
believe your (implied) suspicion that cache'ing is one such factor.
= Joe =
Re: [PATCH] Change Copyright notice to ASF
Posted by Jonas S Karlsson <js...@yesco.org>.
...addendum
h) Remove all the binary copyright notices, they should no longer be needed.
Remove the package org.apache.derby.iapi.reference.Copyright and any
references to it.
/**
IBM Copyright © notice.
*/
public static final String copyrightNotice = org.apache.derby.iapi.reference.Copyright.SHORT_1998_2004;
/Jonas
[VOTE] Change Copyright notice to ASF
Posted by Jalud Abdulmenan <te...@rogers.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
If the issue is just the "re-formatting" of the IBM copyright statement
line, then I think we have achieved consensus and do not need a vote.
However, in the spirit of the Apache way and to allow everyone to
express themselves on the topic, here is the vote again. Closing date
remains Wed Sept 22.
The difference between Option 1 and Option 2 is that Option 1 follows
ASF guidelines while Option 2 keeps the original IBM copyright statement
line.
Please, disregard the difference in the order of copyright statement
lines between Option 1 and 2. I wanted to present Option 2 as provided.
[ ] Option 1: All source code files will only have the following
copyright statement.
CCCC-YYYY are the years found on each file
/*
*
* Copyright 2004 The Apache Software Foundation.
* Copyright CCCC-YYYY IBM Corp.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an ""AS IS"" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/
[ ] Option 2: All source code files will only have the following
copyright statement.
CCCC-YYYY are the years found on each file
/*
*
* (C) Copyright IBM Corp. CCCC, YYYY.
* Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an ""AS IS"" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/
Jalud,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBR5qE2MOhC3LM/1oRAmYyAJ4gOtFP9MTYy8BhtfV6Y6lAlBC0tQCgtdYG
r7tIDQoVUqc6o4Zyp0/2mZk=
=PBcI
-----END PGP SIGNATURE-----
Re: [VOTE] Change Copyright notice to ASF
Posted by "Geir Magnusson Jr." <ge...@gluecode.com>.
On Sep 14, 2004, at 6:38 PM, Jalud Abdulmenan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Geir Magnusson Jr. wrote:
>>
>> I don't understand - has IBM required that we keep IBM copyright on
>> the
>> source?
>>
>
> Geir, I am not privy to any discussion between IBM and ASF. However, we
> are including the IBM copyright statement line, to achieve consensus
> while abiding by ASF copyright guidelines.
I'm familiar with some of the discussion :) and I'd like to figure this
one out, if this was IBM's intention, or something slipped through the
cracks.
geir
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
Re: [VOTE] Change Copyright notice to ASF
Posted by Jalud Abdulmenan <te...@rogers.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John McNally wrote:
> Jalud Abdulmenan wrote:
>
>>
>> However, we
>> are including the IBM copyright statement line, to achieve consensus
>> while abiding by ASF copyright guidelines.
>>
>>
>>
>
> In all previous instances that I am aware of code that has been donated
> to the ASF, previous copyright declarations have been dropped. IBM
> still does have a version of the files in which they have copyright, but
> the copyright holder for the files in a ASF repository is the ASF.
>
> I'm pretty sure there is legal reasoning behind the way I've seen it
> done in the past, but I don't really know what those reasons are. I
> think it probably makes sense to clarify if either option 1 or option 2
> are really acceptable before continuing the vote. But if not, please do
> so before actually performing the work.
>
> John McNally
>
Personally, I prefer to only have the ASF copyright notice in the source
code files and to have the IBM copyright notice in the NOTICE file.
However, based on the previous discussions on this topic, there seem to
be a strong support among the Derby dev community to keep the IBM
copyright notice.
To build a community around Derby and to have an official release, the
copyright notice in the source code files need to change until those
with the expertise and experience make their pronouncements on the final
copyright notice.
In the interim, I am proposing a solution that will allow us to have an
official release as well as foster a community around Derby.
The fact that Derby is in incubation and the lack of clear disapproval
in both the ASF license http://www.apache.org/licenses/LICENSE-2.0 and
the how-to of the ASF license
http://www.apache.org/dev/apply-license.html gives us some flexibility
in using the proposed interim solution.
Jalud,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBR7JN2MOhC3LM/1oRAqBxAJ4zFUTHzJL9h2qKnxDdyuNoKeBArACgvvnY
I2EqMVbavz2ndhJzBZPBh7E=
=uTlH
-----END PGP SIGNATURE-----
Re: [VOTE] Change Copyright notice to ASF
Posted by John McNally <jm...@collab.net>.
Jalud Abdulmenan wrote:
>
> However, we
>are including the IBM copyright statement line, to achieve consensus
>while abiding by ASF copyright guidelines.
>
>
>
In all previous instances that I am aware of code that has been donated
to the ASF, previous copyright declarations have been dropped. IBM
still does have a version of the files in which they have copyright, but
the copyright holder for the files in a ASF repository is the ASF.
I'm pretty sure there is legal reasoning behind the way I've seen it
done in the past, but I don't really know what those reasons are. I
think it probably makes sense to clarify if either option 1 or option 2
are really acceptable before continuing the vote. But if not, please do
so before actually performing the work.
John McNally
Re: [VOTE] Change Copyright notice to ASF
Posted by Jalud Abdulmenan <te...@rogers.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Geir Magnusson Jr. wrote:
>
> I don't understand - has IBM required that we keep IBM copyright on the
> source?
>
Geir, I am not privy to any discussion between IBM and ASF. However, we
are including the IBM copyright statement line, to achieve consensus
while abiding by ASF copyright guidelines.
Jonas S Karlsson wrote:
> Thus I vote for Option 1:
> (i.e. that we should use the apache format of the copyright notice)
>
> +1
>
> (however I'd like to keep the apache on top, since it will have later
> years and will be updated "frequently", and it is the most relevant
> one)
>
Jonas, I am counting your earlier vote for Option 1. You do not need to
re-vote. It make sense to keep the ASF notice on top, so I moved it up.
Jalud,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBR50R2MOhC3LM/1oRAoSXAJ9aWaewIBSvtcN3E6J4LE/NBpCU4QCg6gND
IAPtWY7cbHeCyklfr/waTkk=
=YlMt
-----END PGP SIGNATURE-----
Re: [VOTE] Change Copyright notice to ASF
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Daniel John Debrunner wrote:
>
> For this specific vote, I'm still not sure if a vote is the correct
> approach. If we need to retain copyright notices then option 2) is the
> only choice. I think "retain" could only mean leave as-is, not 'keep a
> modified version'. It may be more a legal decision than a community one.
no, a vote isn't the way to go. since getting the files cleaned
up is one of the graduation criteria, it would essentially be a vote
on whether to ever graduate or not. :-)
see the bottom of http://www.apache.org/licenses/LICENSE-2.0.txt
note that the 'fill in the copyright owner' aspect is directed to
non-apache groups that are using the licence to protect *their* code,
not to apache's own code.
the copyright notice in the files needs to change to:
Copyright 2004 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
information about ibm's involvement needs to go into a NOTICE file; see
http://www.apache.org/licenses/example-NOTICE.txt for an example.
both a LICENCE and a NOTICE file should be at the top level of the
source code repository, *and* in any binary distributions.
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBQUgaIJrNPMCpn3XdAQE0HgP9G2I0q/OFc+7tPyt3Wu3gY9YnOZx8zWTf
BHXSSs5CfqqsUQIDpwpIcSlr/d+wW0OgNJ2gEvM7eGb9uwMejaMud18NBluOkyDe
FL6aQYSTj+jqKxVcfQd21jwMPImU22VmVD2IhJnBGXY/i1WS+8Awo/JnyEcgQw0P
8P0VBz1E6lQ=
=OaDc
-----END PGP SIGNATURE-----
Re: [VOTE] Change Copyright notice to ASF
Posted by "Geir Magnusson Jr." <ge...@gluecode.com>.
On Sep 14, 2004, at 8:31 PM, Daniel John Debrunner wrote:
> Geir Magnusson Jr. wrote:
>
>> I don't understand - has IBM required that we keep IBM copyright on
>> the
>> source?
>
>
> As I understand from the IBM lawyer who deals with ASF, IBM did not
> assign copyright to ASF of the Cloudscape/Derby code, but gave ASF a
> "copyright license grant".
I'll go ask her :)
geir
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
Re: [VOTE] Change Copyright notice to ASF
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Geir Magnusson Jr. wrote:
> I don't understand - has IBM required that we keep IBM copyright on the
> source?
As I understand from the IBM lawyer who deals with ASF, IBM did not
assign copyright to ASF of the Cloudscape/Derby code, but gave ASF a
"copyright license grant".
Given the current issues around open source (caused by SCO), it seems
that ASF (in terms of the Derby community) should ensure that the Derby
handover is handled correctly. If the "copyright licence grant" allows
ASF to remove the IBM copyright, according to an ASF laywer, then it
could be removed. To remove it based upon guesswork just seems wrong.
If you look at section 4c) of the Apache licence 2.0, which includes a
grant of copyright license, for comparision, you will see that it states
that copyright notices must be retained on re-distribution.
We can make progress on most of applying the ASF license by following
Jalud's and Jonas's e-mails. That would leave the code with a IBM and
Apache copyright. This specific issue (removing the IBM copyright) needs
to be addressed one way or the other before Derby can graduate.
For this specific vote, I'm still not sure if a vote is the correct
approach. If we need to retain copyright notices then option 2) is the
only choice. I think "retain" could only mean leave as-is, not 'keep a
modified version'. It may be more a legal decision than a community one.
Dan.
Re: [VOTE] Change Copyright notice to ASF
Posted by "Geir Magnusson Jr." <ge...@gluecode.com>.
On Sep 14, 2004, at 5:47 PM, Jonas S Karlsson wrote:
>
> Daniel John Debrunner wrote:
>> Maybe the exact form doesn't matter, maybe it does?
>> Can someone re-format an existing copyright notice to their own style?
>
> I don't think the *style* of a copyright notice is what makes it
> legally
> binding. I see it mostly as information/reminder.
>
> In my opinion this should suffice:
> - IBM will have copyright notice in the files contributed to ASF by
> IBM.
> - The format of the copyright notice is as suggested by ASF for
> contributed code.
>
> This should keep "IBM" happy as it preserves the copyright ownership
> for IBM,
> as well as follows "ASF" guidlines about copyright notices.
I don't understand - has IBM required that we keep IBM copyright on the
source?
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
Re: [VOTE] Change Copyright notice to ASF
Posted by Jonas S Karlsson <js...@yesco.org>.
Daniel John Debrunner wrote:
> Maybe the exact form doesn't matter, maybe it does?
> Can someone re-format an existing copyright notice to their own style?
I don't think the *style* of a copyright notice is what makes it legally
binding. I see it mostly as information/reminder.
In my opinion this should suffice:
- IBM will have copyright notice in the files contributed to ASF by IBM.
- The format of the copyright notice is as suggested by ASF for contributed code.
This should keep "IBM" happy as it preserves the copyright ownership for IBM,
as well as follows "ASF" guidlines about copyright notices.
Thus I vote for Option 1:
(i.e. that we should use the apache format of the copyright notice)
+1
(however I'd like to keep the apache on top, since it will have later
years and will be updated "frequently", and it is the most relevant
one)
like:
/*
*
* Copyright 2004 The Apache Software Foundation.
* Copyright CCCC-YYYY IBM Corp.
*
Rodent of Unusual Size wrote:
> aaaand.. the answer is: replace the ibm notices with asf ones.
Well, since I'm not really a rodent, and some very large animals are
involved, I'll decline to comment on that. However, it makes me think
of a story of a mouse and an elephant, pick your favourite one...
/Jonas
Re: [VOTE] Change Copyright notice to ASF
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Jalud Abdulmenan wrote:
> With regard to changing the copyright notices, the only issue to resolve
> is to change or not the copyright notices in the source code files.
>
> To resolve the issue the Apache way, I propose a consensus approval
> vote. We can collate the result next Wednesday September 28.
>
> [ ] Option 1: All source code files will only have the following
> copyright statement.
> CCCC-YYYY are the years found on each file
[example snipped]
>
> [ ] Option 2: All source code files will keep the existing copyright
> notices.
I don't think this vote is clear, there is no example for option 2 so
it's hard to tell exactly what we are voting for.
It seems like you are saying the existing IBM notices for licence and
copyright should remain. I don't think anyone has proposed that. I have
been saying that the single IBM copyright statement should remain in the
form that IBM wrote, since it is defining a copyright owned by IBM.
Thus my example would be
/*
*
* (C) Copyright IBM Corp. CCCC, YYYY.
* Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an ""AS IS"" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/
Maybe the exact form doesn't matter, maybe it does?
Can someone re-format an existing copyright notice to their own style?
Dan.
[VOTE] Change Copyright notice to ASF
Posted by Jalud Abdulmenan <te...@rogers.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
With regard to changing the copyright notices, the only issue to resolve
is to change or not the copyright notices in the source code files.
To resolve the issue the Apache way, I propose a consensus approval
vote. We can collate the result next Wednesday September 28.
[ ] Option 1: All source code files will only have the following
copyright statement.
CCCC-YYYY are the years found on each file
/*
*
* Copyright CCCC-YYYY IBM Corp.
* Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an ""AS IS"" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/
[ ] Option 2: All source code files will keep the existing copyright
notices.
Jalud,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBR3OG2MOhC3LM/1oRAt1OAJ92YF9beJgpPblE1QK4jBI7akpzlwCdHn22
0tDIe3eGpCMhmkWilCiCkaQ=
=qSZQ
-----END PGP SIGNATURE-----
Re: [PATCH] Change Copyright notice to ASF
Posted by "Geir Magnusson Jr." <ge...@gluecode.com>.
On Sep 14, 2004, at 3:45 PM, Rodent of Unusual Size wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> aaaand.. the answer is: replace the ibm notices with asf ones.
I was wondering - I always assumed that it would be like other
contributions and become (c) ASF...
geir
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
Re: [PATCH] Change Copyright notice to ASF
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Geir Magnusson Jr. wrote:
> Just for the record, Ken is an ASF founder, an ASF director, and the
> project champion as well as mentor, I think... his opinion counts for
> quite a bit here.
>
> I don't always agree with him, but I certainly pay attention to what he
> says. ;)
skepticism when it comes to ip issues is a mark of our times, and in
order. besides, paying attention to what someone says doesn't mean
he's right. i pay attention to what shrub says, but mostly in order
to be horrified and get my adrenaline running. :-)
republicans as therapy. hmm..
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBQUgp9ZrNPMCpn3XdAQHIbQQA0vTub3GbOdU6Zp8cpKb37315pCBZcJmu
QwGP3V3bZgsTWZX5aBJnsuMizkE8ErKN6T3Ttq9ol4hwmKU6WPINAktvlGEaC2E+
Op45Mbm9JXKs4jw6g+8IoReuzNNgQbmRGKexARv5UxyIDDR5mESnHSxcJEepPyeq
YjMtiFGiHGI=
=4TL1
-----END PGP SIGNATURE-----
Re: [PATCH] Change Copyright notice to ASF
Posted by "Geir Magnusson Jr." <ge...@gluecode.com>.
Just for the record, Ken is an ASF founder, an ASF director, and the
project champion as well as mentor, I think... his opinion counts for
quite a bit here.
I don't always agree with him, but I certainly pay attention to what he
says. ;)
geir
On Sep 14, 2004, at 8:10 PM, Daniel John Debrunner wrote:
> Rodent of Unusual Size wrote:
>
>> aaaand.. the answer is: replace the ibm notices with asf ones.
>
>
> aaaand this is
>
> a) your opinion
>
> b) a fact based upon ???
>
> c) a decision made elsewhere?
>
> d) something else
>
> ??
>
> Confused of Oakland.
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
Re: [PATCH] Change Copyright notice to ASF
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Daniel John Debrunner wrote:
> Rodent of Unusual Size wrote:
>
>> aaaand.. the answer is: replace the ibm notices with asf ones.
>
> aaaand this is
>
> a) your opinion
> b) a fact based upon ???
> c) a decision made elsewhere?
> d) something else
a determination from reviewing archives, the derby grant, and
double-checking with the incubator chair.
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBQUgpeZrNPMCpn3XdAQHxeQQA07qf1+5kmIBsWVCyn6it9tDUnwv6odZK
SmoiZwrRmo7oxY92/SuSZFdMAFtCTEQa3Y68MuUmFjxEMyV3I69RmTCPeCT41Ebi
4LRbGkAyGcviylFluyTdBOV9LVG32aDrmdjOv5mhnqj7FBp1T4y6fQThO7AgtgL3
DOjucpvaTKs=
=Ykub
-----END PGP SIGNATURE-----
Re: [PATCH] Change Copyright notice to ASF
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Rodent of Unusual Size wrote:
> aaaand.. the answer is: replace the ibm notices with asf ones.
aaaand this is
a) your opinion
b) a fact based upon ???
c) a decision made elsewhere?
d) something else
??
Confused of Oakland.
Re: [PATCH] Change Copyright notice to ASF
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
aaaand.. the answer is: replace the ibm notices with asf ones.
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBQUd0cprNPMCpn3XdAQEtbAP/QZWlUe2k+8tO/ai1x+MiqvnZceBbacuF
zgErPCiMv5kZWcbtemyQ2kXDtGNTF/WiWCqNfbVp8eExDZ+j9hlH9gkspsEPaAlt
L8F7uBK6GpQ3kXDjfNG+n2/0G0K3H1jYXrDmkQAu21ky3foolGTaOrd1IM9RXy6R
IxME0hYs/B4=
=e3+G
-----END PGP SIGNATURE-----
Re: [PATCH] Change Copyright notice to ASF
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Jalud Abdulmenan wrote:
> I think that the copyright notices should be changed according to the
> points raised by Jonas, Jason, & Dan.
> Here is my understanding of where we stand so far:
>
>
> 1). All source code files will only have the following copyright statement.
> CCCC-YYYY are the years found on each file
>
> /*
> *
> * Copyright CCCC-YYYY IBM Corp.
There are two proposals for the IBM copyright line.
1a) (as-above) re-format IBM's copyright to ASF standards.
1b) leave IBM's copyright as-is, in the format that IBM uses, since it
is IBM's copyright.
I think 1b) is the safer and more correct.
Dan.
Re: [PATCH] Change Copyright notice to ASF
Posted by Jalud Abdulmenan <te...@rogers.com>.
We need also to consider other issues than just the legal aspect of
changing the copyright notices on the source code files:
- building a community of users and developers beyond IBMers
- fostering an environment where developers (and hopefully companies)
can contribute source code
- reducing the task of commiters/release managers
- avoiding a growing list of copyright statements on source code files
I think that the copyright notices should be changed according to the
points raised by Jonas, Jason, & Dan.
Here is my understanding of where we stand so far:
1). All source code files will only have the following copyright statement.
CCCC-YYYY are the years found on each file
/*
*
* Copyright CCCC-YYYY IBM Corp.
* Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an ""AS IS"" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/
2). A script to do the change
3). A LICENSE file (already in place)
4). A NOTICE file as follows:
=========================================================================
== NOTICE file corresponding to section 4(d) of the Apache License, ==
== Version 2.0, in this case for the Apache Derby distribution. ==
=========================================================================
This product includes software developed by
The Apache Software Foundation (http://www.apache.org/).
Portions of this software was originally based on the following:
- software copyright (c) 1997-2004, IBM Corporation., http://www.ibm.com.
This product includes software developed by the following:
- voluntary contributions made by many individuals on behalf of the
Apache Software Foundation.
5). Remove the binary copyright notices in all source code files and
remove the package org.apache.derby.iapi.reference.Copyright and any
references to it
Re: [PATCH] Change Copyright notice to ASF
Posted by Daniel John Debrunner <dj...@debrunners.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jason Rimmer wrote:
> Unfortunately 'copyright
> licensing' is a phrase whose interpretation is beyond my meager
> knowledge of copyright law. Does this indicate simply a relicensing of
> the copyright or is there more to it?
I'm no expert, but look at item 2 of the ASF license 2.0 for an example
of a grant of copyright licence.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
Thus in my humble (non-legal) opinion, this allows one basically all the
rights of the copyright owner without actually becoming the owner of the
copyright.
Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBRfYrIv0S4qsbfuQRAsF2AJ9+v6QTA/phNTtO6R7jUB/l3XmuRACeOzgA
+zDrauIYLwjZxZnHyfZ6N9E=
=M93o
-----END PGP SIGNATURE-----
Re: [PATCH] Change Copyright notice to ASF
Posted by Jason Rimmer <jr...@irth.net>.
I've been operating under the assumption that 'donation' of code to
Apache included the assignment of copyright. I believe this is what
happened with the Sun donated Tomcat code, and perhaps others.
I confess I'm unable to find mention of any such policy on any Apache
documents therefore I may be mistaken. According to what I have found
copyright assignment is not necessary though conformance/relicensing
with the Apache license is. The closest I've found to a determination
in this respect for the Derby project is RuS' mention of: 'IBM
contributes the Cloudscape code to the ASF, including copyright
licensing and so forth. The result is called Apache Derby.' at
http://ken.coar.org/burrow/?day=2004-08-03. Unfortunately 'copyright
licensing' is a phrase whose interpretation is beyond my meager
knowledge of copyright law. Does this indicate simply a relicensing of
the copyright or is there more to it?
If the Apache Foundation doesn't maintain copyright can it effectively
defend Derby's license? I recall this being an issue for any code
contributed to FSF leading to any such contribution having the copyright
assigned to the FSF. More information is available here,
http://www.gnu.org/philosophy/enforcing-gpl.html.
Daniel John Debrunner wrote:
<snip>
> I believe that since the copyright is IBM's, the original (IBM's)
> statement of copyright (not licence) should remain. The original comment
> in each java file is like
>
> Licensed Materials - Property of IBM
> Cloudscape - Package org.apache.derby.authentication
> (C) Copyright IBM Corp. 1998, 2004. All Rights Reserved.
> US Government Users Restricted Rights - Use, duplication or
> disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
>
>
> The 'Licensed Materials - Property of IBM', 'All Rights Reserved' and
> 'US Government ...' are licensing terms and can be removed and replaced
> as Jonas says above. Which leaves
>
> Cloudscape - Package org.apache.derby.authentication
> (C) Copyright IBM Corp. 1998, 2004. All Rights Reserved.
>
> Licensed under the Apache License, Version 2.0
> [remainder of standard Apache text as in Jonas's e-mail]
>
>
> Not sure what should be done about the 'Cloudscape ...' line, it's
> described as a unique identifer in the IBM copyright guidelines.
>
> Dan.
>
<key snip>
--
Jason Rimmer
jrimmer at irth dot net
Re: [PATCH] Change Copyright notice to ASF
Posted by Daniel John Debrunner <dj...@debrunners.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jonas S Karlsson wrote:
> Hi Jalud and other Derbies,
>
> Regarding the adding of the ASF license I propose the following, in
> order to move forward. I've tried to take care to reflect all parties
> involved, including myself ;), and this is what I came up with.
> (comments, suggestions welcome)
>
> ------------------------------------------------------------
> a) Replace the IBM license information (as propopsed by Jalud) of the
> (.java) files with the following, but keep a modified the IBM
> copyright line, per http://www.apache.org/licenses/LICENSE-2.0.txt:
>
> Copyright [yyyy] IBM Corp.
>
> Licensed under the Apache License, Version 2.0 (the "License");
> you may not use this file except in compliance with the License.
> You may obtain a copy of the License at
>
> http://www.apache.org/licenses/LICENSE-2.0
>
> Unless required by applicable law or agreed to in writing, software
> distributed under the License is distributed on an "AS IS" BASIS,
> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
> See the License for the specific language governing permissions and
> limitations under the License.
I believe that since the copyright is IBM's, the original (IBM's)
statement of copyright (not licence) should remain. The original comment
in each java file is like
Licensed Materials - Property of IBM
Cloudscape - Package org.apache.derby.authentication
(C) Copyright IBM Corp. 1998, 2004. All Rights Reserved.
US Government Users Restricted Rights - Use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
The 'Licensed Materials - Property of IBM', 'All Rights Reserved' and
'US Government ...' are licensing terms and can be removed and replaced
as Jonas says above. Which leaves
Cloudscape - Package org.apache.derby.authentication
(C) Copyright IBM Corp. 1998, 2004. All Rights Reserved.
Licensed under the Apache License, Version 2.0
[remainder of standard Apache text as in Jonas's e-mail]
Not sure what should be done about the 'Cloudscape ...' line, it's
described as a unique identifer in the IBM copyright guidelines.
Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBRerxIv0S4qsbfuQRAoD7AJ9AHZARRD+p9ExAYztACFgW65eswgCfRtWK
epD0ELUReN/QHszOvX4SFwg=
=a94P
-----END PGP SIGNATURE-----
Re: [PATCH] Change Copyright notice to ASF
Posted by Jonas S Karlsson <js...@yesco.org>.
Hi Jalud and other Derbies,
Regarding the adding of the ASF license I propose the following, in
order to move forward. I've tried to take care to reflect all parties
involved, including myself ;), and this is what I came up with.
(comments, suggestions welcome)
------------------------------------------------------------
a) Replace the IBM license information (as propopsed by Jalud) of the
(.java) files with the following, but keep a modified the IBM
copyright line, per http://www.apache.org/licenses/LICENSE-2.0.txt:
Copyright [yyyy] IBM Corp.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
Daniel John Debrunner wrote:
> Does the corporate CLA that Derby was contributed under need to be
> checked to ensure the copyrights can be changed from IBM to ASF?
Jalud Abdulmenan wrote:
> My non-authoritative opinion is that if a project is licensed under the
> ASF license then the source files should have the ASF copyright.
> However, I do not know if this is inline or not with the corporate CLA
> that Derby was contributed under.
I've gotten signals within IBM that IBM still retains the copyright
and that the copyright notices should reflect that. Which there are
provisions for (http://www.apache.org/licenses/LICENSE-2.0.html#apply).
------------------------------------------------------------
b) Add ASF copyright notice to files modified under Derby license.
I.e., ADD the following when there is a community contribution to a file.
Copyright 2004 The Apache Software Foundation.
In 2005 use either of:
Copyright 2005 The Apache Software Foundation.
Copyright 2004, 2005 The Apache Software Foundation.
Leave the IBM notices intact.
One could easily write (perl) scripts that adds/updates these
notices (using information from "svn log ...").
I've done so previously for perforce.
------------------------------------------------------------
c) The [yyyy] in the Copyright should be the years that is contained
in the original files as donated to ASF, using the format
"YYYY" or "CCCC, YYYY" when applicable.
Let me explain where these years come from, since I did a scripted
update of all of them a few months ago. I traced back in our source
code repository from when the file was first created (CCCC).
YYYY was set to the year the file was last "move"/changed package
name, or accumulated at least 5% (of the lines) had been modified.
Daniel John Debrunner wrote:
> Any reason you chose a fixed copyright date (2001-2004) rather than the
> valid copyright date each file had on the handover, e.g. 1997-2004?
Jalud Abdulmenan wrote:
> I took the date from some of the files that I was going over.
> I was a little bit hesitant even for 2001-2004. I prefer just 2004 since
> that is the year derby came under the ASF license.
Apache says in: http://www.apache.org/dev/apply-license.html :
> Do not worry about consistency in the first year -- it is
> not supposed to be uniform and should never be dated prior
> to the year of first creation.
As I understand it, if there are no other copyright than the Apache
(would IBM's ever be removed), then Apache considered it important
that the first year mentioned reflects the creation of the file.
Otherwise, it seems that the years should reflect when it was first
publicized by ASF.
Apache says on http://www.apache.org/dev/apply-license.html:
> ... years given start with the first publication year of the file
> contents (the authored expression) ...
------------------------------------------------------------
And to comply with http://www.apache.org/dev/apply-license.html :
d) Copy http://www.apache.org/licenses/LICENSE-2.0.txt into /LICENSE
e) Create a file /NOTICE containing:
---
This product includes software developed by
The Apache Software Foundation (http://www.apache.org/).
This software consists of voluntary contributions
made by many individuals on behalf of the Apache
Software Foundation, and was originally based on
Cloudscape software, copyright International
Business Machines Inc., http://www.ibm.com .
---
( inspired from public record IBM donations
http://www.apache.org/foundation/records/ )
------------------------------------------------------------
f) I further suggest that the updates not be submitted as patches, but
instead that a (perl?) script is given that is tested, and can be run
by a committer.
I'm aware that Apache says:
>For Apache software, we strongly recommend checking the diffs of each
>file and commit only one directory at a time (bottom-up) so that the
>changes can be verified without overwhelming reviewers.
But with 1298 .java-files, I think even a 123 directories with a patch
each is really pushing it.
I suggest the script that performs the updates on a directory and its
subdirectories, that it only touches files that are actually changed,
so that it can be re-run at any time, only affecting files that need
change. Having a script also allows any future changes to be readily
applied.
Jalud Abdulmenan wrote:
> I will submit a modified patch when a consensus is reached on these two
> questions.
------------------------------------------------------------
g) I'm still trying to get a copy of the IBM Corporate CLA to read, since
it may be easier to comply with it then, and might simplify some
issues. Maybe somebody at Apache has an available copy?
---
I'm currently working for IBM: 2 years DB2 Everyplace; Now 2 years Cloudscape;
Before that I did research on databases - Scalable Distributed Data Structures:
3 years in Amsterdam (CWI); 3 years at Link��ping University, Sweden.
/Jonas
Re: [PATCH] Change Copyright notice to ASF
Posted by Jalud Abdulmenan <te...@rogers.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel John Debrunner wrote:
>
> Does the corporate CLA that Derby was contributed under need to be
> checked to ensure the copyrights can be changed from IBM to ASF?
>
> Any reason you chose a fixed copyright date (2001-2004) rather than the
> valid copyright date each file had on the handover, e.g. 1997-2004?
>
> Dan.
My non-authoritative opinion is that if a project is licensed under the
ASF license then the source files should have the ASF copyright.
However, I do not know if this is inline or not with the corporate CLA
that Derby was contributed under.
I took the date from some of the files that I was going over.
I was a little bit hesitant even for 2001-2004. I prefer just 2004 since
that is the year derby came under the ASF license.
I will submit a modified patch when a consensus is reached on these two
questions.
Jalud
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBOzmw2MOhC3LM/1oRAsRRAJwKqc5kOYrDtgpHqsyjpwgYt8TYYgCg5GFI
CBe/LyWKJq+Yxb2kJ2nxmBQ=
=8wg1
-----END PGP SIGNATURE-----
Re: [PATCH] Change Copyright notice to ASF
Posted by Daniel John Debrunner <dj...@debrunners.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Does the corporate CLA that Derby was contributed under need to be
checked to ensure the copyrights can be changed from IBM to ASF?
Any reason you chose a fixed copyright date (2001-2004) rather than the
valid copyright date each file had on the handover, e.g. 1997-2004?
Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBOylSIv0S4qsbfuQRAq4RAJ9/mXLbYjF7kILz4vBw1bG6AVDfIwCgo9N+
EbmUAos24W0wqMMiJogdAv4=
=uY6A
-----END PGP SIGNATURE-----
[PATCH] Change Copyright notice to ASF
Posted by Jalud Abdulmenan <te...@rogers.com>.
Nothing fancy, just changing IBM Copyright notices to ASF. However, it
affects a lot of files.
Attached is a unified diff file.
Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Posted by Jan Hlavatý <hl...@code.cz>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I suspect "rws" and "rwd" do not sync at all on OSX - these speeds match the buffered writes.
Thats very suspicious.
Looks like we need to have the write method configurable somehow...
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQEVAwUBQTrajXFDePgyse5HAQKGXwf/eewbXVaJvG0zdguulorYel+/LxOtZzHs
eU8Ud1MLi4qmVtnopX9UCANb8DxeTokuvHxQR8hSw23gBcBRoM7n+Zp3lHQNlEPO
U2o1sHN3d7hNVJUNyV/iUwXCDsNK7OtvhQ03qmZejGwok84kxTQdfckgQ/7UkbG5
zYDHOU3YL/52iD9At6WyXk54mwYGdeFkNCqD2o+JdYunwOSVNC6Pn+IdCKqIANRk
t2QucoWQBKMvCojRitAC86sRi7NhzbDcBB/iYn9641xBD2vpHQ+zrJxKVvZX0voN
2Tw1BiG5/9YZrVpHB4KbNlq1Vvj5hzATSZj9fzs82d6EvNpT1tn05w==
=+H1f
-----END PGP SIGNATURE-----
Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Posted by Mi...@objectweb.org.
Jan Hlavatý <hl...@code.cz> wrote on 09/15/2004 12:35:40 PM:
> Most probably because the implementation does not what it is supposed to
do,
> and does ordinary "rw" mode instead.
I don't think so. I added a couple of tests to the original code. #16 is
the same as
#15 with a channel.force(false) added to each write. The total bandwidth
is
less than 1/2 that of #15, suggesting that Jan is correct.
But test #17 uses "rw" without a force, (which is what I think Jan
suggested)
and for this test, the write bandwidth is 255 MB/s, 10x faster than #16
and
4x faster than #15.
I'm not really sure what can be concluded from this. How can we be
certain
that "rwd" is honoring the guarantee not to return till data is on media?
Michael Giroux, Objectweb.org
-----------------------------------------------------------------------
15. Testing preallocated file using direct buffer + FileChannel "rwd"
-----------------------------------------------------------------------
Chunk size: 4228 bytes
Count: 5000
Total time: 329 ms
Writes per second: 15197.568 writes/s
Time per chunk: 0.066 ms
Write bandwidth: 61.0MB/s
----------------------------------------------------------------------------
16. Testing preallocated file using direct buffer + FileChannel "rwd"
force(false)
----------------------------------------------------------------------------
Chunk size: 4228 bytes
Count: 5000
Total time: 859 ms
Writes per second: 5820.722 writes/s
Time per chunk: 0.172 ms
Write bandwidth: 23.0MB/s
------------------------------------------------------------------------------
17. Testing preallocated file using direct buffer + FileChannel "rw" no
force
------------------------------------------------------------------------------
Chunk size: 4228 bytes
Count: 5000
Total time: 79 ms
Writes per second: 63291.139 writes/s
Time per chunk: 0.016 ms
Write bandwidth: 255.0MB/s
C:\GIROUX\HOWL\Derby Benchmark>
Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Posted by Steen Jansdal <st...@jansdal.dk>.
Mike Matrigali wrote:
> I have also observed that syncing does not take place on windows
> platform if "write cache" is enabled. Note that the microsoft
> documentation for this setting notes that data may be corrupted if it is
> enabled. Unfortunately I think this option is enabled by default often
> (I don't know if it is up to box hardware vendor, disk hardware vendor,
> or OS software configuration).
>
> The question is should the software not allow the user to tune this
> behavior? For instance on machines with redundant power supplies it may
> be acceptable for the application to choose to run faster at a very low
> risk. I believe laptops fall into this category. Note that I am not
> arguing that there is ZERO risk.
>
> When the change was made to go to from file sync to rws/rwd mode, suresh
> and I worried about this issue, but the performance gain was so great
> that I felt the change was worth making. Users can turn off "write
> cache" to be safer, microsoft documentation notes the safety tradeoffs
> of the option. Client applications the find this risk totally
> unexceptable can use the property sent to the list to configure the
> software to always use the old file sync method.
>
> If anyone has time and access it might be interesting to see what other
> databases do about this issue. A simple benchmark that inserted one row
> into a table and then updated a single integer column value to a
> different value each time over and over again in autocommit mode should
> be enough. Any database that can do this at a rate greated than I/O
> bandwith of the underlying disk is not syncing the log on commit. Watch
> out for underlying hardware, I got some wierd results on a relatively
> inexpensive piece of server hardware, until I realized that it's
> standard controller also included a battery backed 128 meg cache that
> sat between the OS and disk - this thing is exactly what you need to get
> rid of the standard short transaction log I/O bottleneck - works great
> for derby.
>
> Going forward it is likely users will request either no logging or in
> memory logging options. I believe many open source/inexpensive
> databases provide these options - often making them the default out of
> box configurations. These are technically not very hard to provide, if
> it is acceptable that failures will likely be unrecoverable databases.
> What do people think about these types of features?
>
I 100% agree with you. We need this option. I can imagine a lot of
places where you don't need the fail-safe feature.
One of first things people do when they are checking out a new database
is writing a little benchmark program inserting some records, querying
them and compare them with a database they already know. One of these
known database are hsqldb which is very fast, but even though people
think it's failsafe because it uses a log file too, it's not. It has
a log sync thread that by default commits the log once every minute.
Steen
Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I have also observed that syncing does not take place on windows
platform if "write cache" is enabled. Note that the microsoft
documentation for this setting notes that data may be corrupted if it is
enabled. Unfortunately I think this option is enabled by default often
(I don't know if it is up to box hardware vendor, disk hardware vendor,
or OS software configuration).
The question is should the software not allow the user to tune this
behavior? For instance on machines with redundant power supplies it may
be acceptable for the application to choose to run faster at a very low
risk. I believe laptops fall into this category. Note that I am not
arguing that there is ZERO risk.
When the change was made to go to from file sync to rws/rwd mode, suresh
and I worried about this issue, but the performance gain was so great
that I felt the change was worth making. Users can turn off "write
cache" to be safer, microsoft documentation notes the safety tradeoffs
of the option. Client applications the find this risk totally
unexceptable can use the property sent to the list to configure the
software to always use the old file sync method.
If anyone has time and access it might be interesting to see what other
databases do about this issue. A simple benchmark that inserted one row
into a table and then updated a single integer column value to a
different value each time over and over again in autocommit mode should
be enough. Any database that can do this at a rate greated than I/O
bandwith of the underlying disk is not syncing the log on commit. Watch
out for underlying hardware, I got some wierd results on a relatively
inexpensive piece of server hardware, until I realized that it's
standard controller also included a battery backed 128 meg cache that
sat between the OS and disk - this thing is exactly what you need to get
rid of the standard short transaction log I/O bottleneck - works great
for derby.
Going forward it is likely users will request either no logging or in
memory logging options. I believe many open source/inexpensive
databases provide these options - often making them the default out of
box configurations. These are technically not very hard to provide, if
it is acceptable that failures will likely be unrecoverable databases.
What do people think about these types of features?
Michael.Giroux@objectweb.org wrote:
> I've done a bit more testing on this and discovered that results are
> significantly different if I disable the write cache on the device. This
> makes me question whether "rwd" is actually getting the data to disk
> before it returns to the program.
>
> rest deleted ...
Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Posted by Mi...@objectweb.org.
> Although the throughput varies all over the place, the
> most consistent results occur when doing a write/force
> sequence with the system write cache disabled.
Should say "with or without the system write cache disabled."
Michael Giroux
Michael.Giroux@objectweb.org
09/17/2004 02:00 PM
Please respond to
"Derby Development" <de...@db.apache.org>
To
"Derby Development" <de...@db.apache.org>
cc
Subject
Re: java1.4.2 "rws" mode - log write performance - OSX numbers
I've done a bit more testing on this and discovered that results are
significantly different if I disable the write cache on the device. This
makes me question whether "rwd" is actually getting the data to disk
before it returns to the program.
I'm using Windows XP SP2. The default setting for the IDE drive (windows
device manager) is write cache enabled. According to the dialog box in the
device manager:
"This setting enables write caching to improve disk performance, but a
power outage or equipement failure might result in data loss or
corruption."
With write cache enabled, the "rwd" tests are doing approximately 1100
writes per second to an existing file when the test only does write().
When I follow the write with a channel force(), then the number of writes
per second drops to 28 per second.
With write cache disabled, I'm seeing 100 writes per second to existing
file when doing only the write(). Write() followed by force() does
approximately 27 write/sec.
Although the throughput varies all over the place, the most consistent
results occur when doing a write/force sequence with the system write
cache disabled.
This leads me to suspect that at least for a windows platform, it is
necessary to actually do the channel force() if you want to be certain the
write went all the way to the media.
Michael Giroux, objectweb.org
Jan Hlavatý <hl...@code.cz>
09/15/2004 12:35 PM
Please respond to
"Derby Development" <de...@db.apache.org>
To
Derby Development <de...@db.apache.org>
cc
Subject
Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Michael.Giroux@objectweb.org wrote:
> On the survace, test #11 and #15 appear to be very similar, yet there is
> a 14x improvement in #15.
>
> Does anyone know enough about the IO to be able to explain why
> "rw" write+force is 14x slower than "rwd" write?
>
> Reading the Javadocs, using "rwd" the write blocks until the data is
> on disk. With "rw" the write does not block, but the force(false)
> does block. Since the same amount of data is involved in both cases,
> can anyone explain why the "rwd" write is so much faster?
Most probably because the implementation does not what it is supposed to
do,
and does ordinary "rw" mode instead.
Jan
Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Posted by Mi...@objectweb.org.
I've done a bit more testing on this and discovered that results are
significantly different if I disable the write cache on the device. This
makes me question whether "rwd" is actually getting the data to disk
before it returns to the program.
I'm using Windows XP SP2. The default setting for the IDE drive (windows
device manager) is write cache enabled. According to the dialog box in the
device manager:
"This setting enables write caching to improve disk performance, but a
power outage or equipement failure might result in data loss or
corruption."
With write cache enabled, the "rwd" tests are doing approximately 1100
writes per second to an existing file when the test only does write().
When I follow the write with a channel force(), then the number of writes
per second drops to 28 per second.
With write cache disabled, I'm seeing 100 writes per second to existing
file when doing only the write(). Write() followed by force() does
approximately 27 write/sec.
Although the throughput varies all over the place, the most consistent
results occur when doing a write/force sequence with the system write
cache disabled.
This leads me to suspect that at least for a windows platform, it is
necessary to actually do the channel force() if you want to be certain the
write went all the way to the media.
Michael Giroux, objectweb.org
Jan Hlavatý <hl...@code.cz>
09/15/2004 12:35 PM
Please respond to
"Derby Development" <de...@db.apache.org>
To
Derby Development <de...@db.apache.org>
cc
Subject
Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Michael.Giroux@objectweb.org wrote:
> On the survace, test #11 and #15 appear to be very similar, yet there is
> a 14x improvement in #15.
>
> Does anyone know enough about the IO to be able to explain why
> "rw" write+force is 14x slower than "rwd" write?
>
> Reading the Javadocs, using "rwd" the write blocks until the data is
> on disk. With "rw" the write does not block, but the force(false)
> does block. Since the same amount of data is involved in both cases,
> can anyone explain why the "rwd" write is so much faster?
Most probably because the implementation does not what it is supposed to
do,
and does ordinary "rw" mode instead.
Jan
Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Posted by Jan Hlavatý <hl...@code.cz>.
Michael.Giroux@objectweb.org wrote:
> On the survace, test #11 and #15 appear to be very similar, yet there is
> a 14x improvement in #15.
>
> Does anyone know enough about the IO to be able to explain why
> "rw" write+force is 14x slower than "rwd" write?
>
> Reading the Javadocs, using "rwd" the write blocks until the data is
> on disk. With "rw" the write does not block, but the force(false)
> does block. Since the same amount of data is involved in both cases,
> can anyone explain why the "rwd" write is so much faster?
Most probably because the implementation does not what it is supposed to do,
and does ordinary "rw" mode instead.
Jan
Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Posted by Mi...@objectweb.org.
On the survace, test #11 and #15 appear to be very similar, yet there is
a 14x improvement in #15.
Does anyone know enough about the IO to be able to explain why
"rw" write+force is 14x slower than "rwd" write?
Reading the Javadocs, using "rwd" the write blocks until the data is
on disk. With "rw" the write does not block, but the force(false)
does block. Since the same amount of data is involved in both cases,
can anyone explain why the "rwd" write is so much faster?
Michael Giroux, ObjectWeb.org
> ------------------------------------------------------------------------
> 11. Testing preallocated file using direct buffer + FileChannel "rw" +
> force(false)
> ------------------------------------------------------------------------
> Chunk size: 4228 bytes
> Count: 10000
> Total time: 10226 ms
> Writes per second: 977.899 writes/s
> Time per chunk: 1.023 ms
> Write bandwidth: 3.0MB/s
>
> ------------------------------------------------------------------------
> 15. Testing preallocated file using direct buffer + FileChannel "rwd"
> ------------------------------------------------------------------------
> Chunk size: 4228 bytes
> Count: 10000
> Total time: 947 ms
> Writes per second: 10559.662 writes/s
> Time per chunk: 0.095 ms
> Write bandwidth: 42.0MB/s
>