[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: More ext3 fileserver woes ...


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


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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]