Douglas Gilbert wrote:
> There is definitely something strange going on here.
> As the bonnie test below shows, the SCSI disk used
> for my tests should vastly outperform the old IDE one:
First thank you and others with my clueless investigation about
the module loading under Debian GNU/Linux. (I should have known
that Debian uses a very special module setup.)
Anyway, I used to think SCSI is better than IDE in general, and
the post was quite surprising.
So I ran the test on my PC.
On my systems too, the IDE beats SCSI hand down with the test case.
BTW, has anyone noticed that
the elapsed time of SCSI case is TWICE as long if
we let the previous output of the test program stay before
running the second test? (I suspect fdatasync
takes time proportional to the (then current) file size, but
still why SCSI case is so long is beyond me.)
Eg.
ishikawa@duron$ ls -l /tmp/t.out
ls: /tmp/t.out: No such file or directory
ishikawa@duron$ time ./xlog /tmp/t.out fsync
real 0m38.673s <=== my scsi disk is slow one to begin with...
user 0m0.050s
sys 0m0.140s
ishikawa@duron$ ls -l /tmp/t.out
-rw-r--r-- 1 ishikawa users 112000 Mar 5 06:19 /tmp/t.out
ishikawa@duron$ time ./xlog /tmp/t.out fsync
real 1m16.928s <=== See TWICE as long!
user 0m0.060s
sys 0m0.160s
ishikawa@duron$ ls -l /tmp/t.out
-rw-r--r-- 1 ishikawa users 112000 Mar 5 06:20 /tmp/t.out
ishikawa@duron$ rm /tmp/t.out <==== REMOVE the file and try again.
ishikawa@duron$ time ./xlog /tmp/t.out fsync
real 0m40.667s <==== Half as long and back to original.
user 0m0.040s
sys 0m0.120s
iishikawa@duron$ time ./xlog /tmp/t.out xxx
real 0m0.012s <=== very fast without fdatasync as it should be.
user 0m0.010s
sys 0m0.010s
ishikawa@duron$
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 07 2001 - 21:00:16 EST