* sync() broken for raw devices in 2.4.x??
@ 2001-01-02 0:50 stewart
2001-01-02 1:35 ` Andi Kleen
0 siblings, 1 reply; 4+ messages in thread
From: stewart @ 2001-01-02 0:50 UTC (permalink / raw)
To: linux-kernel
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: sync() broken for raw devices in 2.4.x??
2001-01-02 0:50 sync() broken for raw devices in 2.4.x?? stewart
@ 2001-01-02 1:35 ` Andi Kleen
2001-01-02 15:26 ` stewart
2001-01-02 17:57 ` stewart
0 siblings, 2 replies; 4+ messages in thread
From: Andi Kleen @ 2001-01-02 1:35 UTC (permalink / raw)
To: stewart; +Cc: linux-kernel
On Mon, Jan 01, 2001 at 07:50:31PM -0500, stewart@neuron.com wrote:
>
> 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".
Just a minor correction: this is not a raw partition, but a buffered blockdevice.
If you want a real rawdevice (where sync is a noop because all IO goes
synchronously to disk) you need to bind a character raw device to the
block device first using the raw util.
>From a quick look sync_buffers() [which implements fsync on block devices]
has not changed significantly between 2.2 and 2.4 and uses the same algorithm.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: sync() broken for raw devices in 2.4.x??
2001-01-02 1:35 ` Andi Kleen
@ 2001-01-02 15:26 ` stewart
2001-01-02 17:57 ` stewart
1 sibling, 0 replies; 4+ messages in thread
From: stewart @ 2001-01-02 15:26 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
Thanks, Andi. In which case sync() for direct buffered block
device access would seem to be broken in 2.4.0-prerelease.
stewart
On Tue, 2 Jan 2001, Andi Kleen wrote:
> On Mon, Jan 01, 2001 at 07:50:31PM -0500, stewart@neuron.com wrote:
> >
> > 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".
>
> Just a minor correction: this is not a raw partition, but a buffered blockdevice.
> If you want a real rawdevice (where sync is a noop because all IO goes
> synchronously to disk) you need to bind a character raw device to the
> block device first using the raw util.
>
> >From a quick look sync_buffers() [which implements fsync on block devices]
> has not changed significantly between 2.2 and 2.4 and uses the same algorithm.
>
> -Andi
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: sync() broken for raw devices in 2.4.x??
2001-01-02 1:35 ` Andi Kleen
2001-01-02 15:26 ` stewart
@ 2001-01-02 17:57 ` stewart
1 sibling, 0 replies; 4+ messages in thread
From: stewart @ 2001-01-02 17:57 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
Thanks for the correction. I am using a buffered block device
then, not a real synchronous raw device.
stewart
On Tue, 2 Jan 2001, Andi Kleen wrote:
> On Mon, Jan 01, 2001 at 07:50:31PM -0500, stewart@neuron.com wrote:
> >
> > 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".
>
> Just a minor correction: this is not a raw partition, but a buffered blockdevice.
> If you want a real rawdevice (where sync is a noop because all IO goes
> synchronously to disk) you need to bind a character raw device to the
> block device first using the raw util.
>
> >From a quick look sync_buffers() [which implements fsync on block devices]
> has not changed significantly between 2.2 and 2.4 and uses the same algorithm.
>
> -Andi
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-01-02 18:26 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-01-02 0:50 sync() broken for raw devices in 2.4.x?? stewart
2001-01-02 1:35 ` Andi Kleen
2001-01-02 15:26 ` stewart
2001-01-02 17:57 ` stewart
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).