Hi, On Wed, Jun 12, 2002 at 10:10:56AM +1000, Neil Brown wrote: > Actually.. I might be misinterpreting this output. > This doesn't necessarily mean they are in the wrong order. > It could happen if lots of buffers are on the dirty list with the same > flush time. The get flushed out in groups of 32 and these messages > could be one for each group, that are starting at approximately 0.15 > second intervals. > > So mayby this patch is OK after all. I've just pushed an initial version of my testdrive test disk code to http://people.redhat.com/sct/patches/testdrive/ It builds either monolithic or as a module (load testdrive.o before loop.o). The module accepts parameters enable_testdrive=n (non-zero to enable, defaults ON) enable_trace=n (non-zero to enable, defaults OFF) With the modified loop.o, you just stack the loop device on top of any existing block device, and the testdrive bits will track all outstanding IO on the device. The default test code just watches for misuse of IO --- it tracks every bh in progress and watches for the same bh being reused before completion, or for two outstanding IO request on the same disk sector at the same time. If you enable tracing, it traces every IO by device, sector number and r/w, and completion by success/failure, to KERN_DEBUG (I use serial console to capture it). I find it really convenient to be able to load the modules and then simply "mount -o loop /dev/foo /mnt/bar", and have been using this to reproduce Neil's bug report concerning multiple IOs to the same address being seen on soft raid. The tracing is flexible enough that it would be easy to add flushtime output without requiring a reboot, and to trace the order in which IOs are getting submitted to the device underneath. Cheers, Stephen
