On Sep 26, 9:40 am, Vide <[EMAIL PROTECTED]> wrote: > iscsi: host reset > succeeded > iscsi: host reset > succeeded > sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK > driverbyte=DRIVER_TIMEOUT,SUGGEST_OK > end_request: I/O error, dev sdb, sector > 15552143 > device-mapper: multipath: Failing path > 8:16. > sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK > driverbyte=DRIVER_TIMEOUT,SUGGEST_OK > end_request: I/O error, dev sdb, sector > 15552407 > > (lots of write errors)
I do not think this is enough info. Do you just see the above then see write errors on the FS? Or do you see a error message about the other path failing? The above errors are expected and ok because of the nic port going up and down, and they only indicate that on one path we got errors and that multipath handled it by failing a path. If you run iscsiadm -m session -P 3 You should see at least two sessions. One session would have sdb and the other session should have some other sdX that we did not see errors for in the log snippets. If you run multipath -ll you should see the other sdX which is the other path we care about. Make sure this is on a different session than sdb. Then in the log if you see errors like above for this other sdX then there is nasty problem, and if you could send the rest of the log for those errors it would be helpful. Also Konrads suggestion to use 'queue_if_no_path' or no_path_retry would fix the problem where if all paths are going offline for a legitimate reason then dm-multipath would not fail IO to the FS as quickly or at all depending on which setting you use. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
