I have a sync()/fdatasync() intensive application that is designed to work
on both raw files and raw partitions. Today I upgraded my kernel to the
new pre-release and found that my benchmark program would no longer finish
when handed a raw partition. I've written a small Java program (my app is
in Java) which demonstrates the bug. Make foo.dat a raw scsi partition to
re-produce. In my case it's "mknod foo.dat b 8 18".
// -----------------------------------------------------
import java.io.*;
public class sync {
public static void main(String args[]) throws Exception {
long ops = Long.parseLong(args[0]);
byte dat[] = new byte[Integer.parseInt(args[1])];
RandomAccessFile rf = new RandomAccessFile("foo.dat", "rw");
long time = System.currentTimeMillis();
long t2 = time;
for (int i=0; i<ops; i++) {
rf.write(dat);
rf.getFD().sync();
if (i%100 == 0) {
long tm = System.currentTimeMillis();
System.out.println("i="+i+" sync avg ms="+((tm-t2)/100));
t2 = tm;
}
}
time = System.currentTimeMillis()-time;
System.out.println("time = "+time+"ms");
System.out.println(((ops*1000)/time)+" ops/sec");
}
}
// -----------------------------------------------------
I've included 2.2.17 as a baseline for comparison w/ 2.4.0-prerelease.
Watch the avg sync times. The tests were run with the command-line:
java sync 10000 4096
2.2.17 on an ext2 file looks like this:
i=0 sync avg ms=0
i=100 sync avg ms=11
i=200 sync avg ms=13
...
i=9700 sync avg ms=21
i=9800 sync avg ms=21
i=9900 sync avg ms=21
time = 153510ms
65 ops/sec
2.4.0 on an ext2 file looks like this:
=0 sync avg ms=0
i=100 sync avg ms=13
i=200 sync avg ms=13
...
i=9700 sync avg ms=16
i=9800 sync avg ms=16
i=9900 sync avg ms=15
time = 140780ms
71 ops/sec
OK, that's better. My benchmarks confirm that under ext2, 2.4.0 is
generally superior, though I'm still getting some suspicious hangs.
I'll report back on that if I can reproduce it with a sample program.
2.2.17 with a raw partition:
i=0 sync avg ms=0
i=100 sync avg ms=0
i=200 sync avg ms=0
...
i=9700 sync avg ms=0
i=9800 sync avg ms=1
i=9900 sync avg ms=1
time = 22825ms
438 ops/sec
2.4.0 with a raw partition:
i=0 sync avg ms=0
i=100 sync avg ms=0
i=200 sync avg ms=0
...
i=9700 sync avg ms=39
i=9800 sync avg ms=39
i=9900 sync avg ms=40
time = 202406ms
49 ops/sec
OK, 2.4.0 gets progressively (visibly) slower as the test goes on. Even
under 2.2.17 the test would cycle between 0-6ms over several thousand
iterations. This could be sped up/slowed by changing the data volume.
2.4.0, however, never recovers and sync() times will become infinitely
large. This explains why my benchmarks never complete.
The system in this case is a dual p2-450 512MB ram and SCSI disks. I have
not tested this with IDE drives under 2.4.0 nor have I performed these
tests under other 2.4.x test kernels.
Stewart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
