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-scsi" in the body of a message to [EMAIL PROTECTED]

Reply via email to