I know I said I would not do it, but I was without internet access for some time and the request based multipath stuff was the only code on my computer, so I updated the code and fixed the locking and irq bugs. I stuck it in the multipath branch of my iscsi tree here http://kernel.org/git/?p=linux/kernel/git/mnc/linux-2.6-iscsi.git;a=summary I am not looking for a formal review of the patches so I will not send the patches to the list unless someone asks. I just updated the code due to popular request and because I was testing the request struct timer patch :) It compiles. It works, but has not been tested very hard. There are lots of things I did not handle because if we move it to dm then I need to update some of that code to handle things properly. And there is a nasty performance problem. I think this is due to me using the block layer functions as-is in a little less than optimal way. It is about a 1-2% drop for normal setups like when using qla2xxx or lpfc or iscsi, but when using libata with very small IOs we hit some problems that I believe are result of me using the block layer with no modifications to the queueing, unplugging and locking. I will continue to look into this. I did not hook this into Jens's cmd type stuff and my patch to move the scsi hw handlers to the scsi layer. I did not have time. The code does have us send the sense and request->errors to the multipath layer for read and writes and failover IOs, and the io scheduler is in the correct place now. I still have to hook into the dm layer or we have to figure out what we are going to do about that - maybe just port multipath-tools to the new multipath layer (this should not be too bad since we can add a interface similar to dm's very easily). So Alasdair tell me what you want to do and if you have time? If you are busy Mike Anderson and I and the NEC guys could probably take this task and that way we can get multipath development going again. - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
