On Tue, 30 Apr 2002, Andrew Morton wrote: > David Mansfield wrote: > > > > ... > > One interesting and unexpected result is that running inside a looped back > > filesystem 1gb in size increases performance 4-fold from running on the > > real filesystem! That is, ext3-ordered looped on top of ext3-ordered is > > much faster than ext3-ordered! This is on kernel 2.4.17-rc2-aa2, which is > > a bit old, so it could be meaningless.... > > Heh. The loop driver tells lies: when it signals I/O > completion, your data is still floating about in memory, > unwritten. So yup, it'll run quicker. > > > P.S. I created a benchmark of this phenomenon called blktest.c. > > Great stuff, thanks. > I've done some more testing, and there's definitely something fishy going on here. I tested on my home computer (1GHZ Athlon, ATA133 IDE disk) and got numbers like: Kernel 2.4.19-pre7 150 blks/sec ext2 100 blks/sec ext3-ordered 96 blks/sec ext3-writeback Kernel 2.4.19-pre7-aa3 168 blks/sec ext2 98 blks/sec ext3-ordered 96 blks/sec ext3-writeback. So on this system, it seems like ext2 is a 50% improvement. Maybe this is just to be expected... And for reference, on the server our application is running on (1ghz Intel, SCSI U160 drive, 2.4.19-pre7-aa2, 2gb ram with blk high io enabled) 44 blks/sec ext3-ordered. (half as fast as that inferior system). The last thing I tried is running the program on a server here running the beta of 'Red Hat Advanced Server' which is running their kernel '2.4.9-26beta.31' and I got: 1399 blks/sec ext3-ordered !!! It turns out that this kernel ignores the O_SYNC on open... ha. David P.S. one other note. Usually I let this my benchmark run for a few minutes, and yet, when the individual process scores (4 process test case) print out, I see that one process has made almost, or exactly 0 progress. 0 blocks written in a minute. -- /==============================\ | David Mansfield | | david@cobite.com | \==============================/
