Hello Chris, I was hunting one ext3/4 barrier related bug and so I used your barrier-test IO scheduler. It was quite helpful so thank you for it. For my purposes, I had to tweak it a bit to trigger my problem. I'm not sure if you keep the scheduler somewhere but if yes, I hope my patches could be of use. Patch 1 implements raw support for handling reads - we don't have to flush our delayed writes everytime a read comes. It is enough to do so when some delayed write overlaps with a read. Scanning the list of delayed writes is slow but who really cares for barrier-test :) Patch 2 implements another criteria for reordering requests and triggering reboot. Filesystem can flag certain bios as special. These bios will go directly to the backing storage and when they complete, reboot is triggered if there are enough pending writes. Filesystem can use the flag when writing commit blocks, superblocks or similarly sensitive metadata to verify whether barriers are issued in all the necessary places. Honza -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
