Here are some quick-fixes for the new dm-multipath module. Based on 2.6.0-udm3 + Christophe's bio_list patches from Jan 10. Revision 1: When a bio is submitted to the block-layer, several of the fields in that bio will have changed by the time it completes. In particular, the bi_sector field will be different, the bi_size field will be zero, and the bi_bdev and bi_idx fields may have changed as well. This creates a problem for some of the Device-Mapper modules (like dm-multipath) that may want to redrive a bio. Save the necessary bio fields in the target_io structure just before calling generic_make_request(), and restore those bio fields just before calling the target's end_io() routine. This ensures that the target module sees the bio exactly as it was following the map() routine. Revision 2: path->fail_count needs to be initialized to non-zero, or a failed path will never actually be failed. Set to 1 for now, but this number can be increased if we don't want to fail the path on the very first I/O error. Revision 3: Make a #define for the minimum-io value. Revision 4: We can't depend on the test_bio being the same every time it is submitted. Need to reset some of the fields in the bio each time. Revision 5: Add a pointer from the priority-group back to the multipath context. Revision 6: Change the failed_ios list in the multipath structure from a stack to a queue using the new bio_list services. Revision 7: In test_path, instead of driving the test I/O, queue it on a list. When all test I/Os have been queued, they can then be driven down without having to hold the path_lock. Revision 8: m->path_lock needs to be locked with spin_lock_irqsave() and unlocked with spin_lock_irqrestore(). Revision 9: If a test bio completes successfully and the path is currently invalid, reactivate the path. -- Kevin Corry kevcorry@xxxxxxxxxx http://evms.sourceforge.net/