Menu
▾
▴
scst-devel
|
From: Stanley S. <sta...@ro...> - 2007-12-18 06:34:21
|
Ok, gimme a clue here. I've applied all patches to kernel 2.6.22 and iscsi release patch. I'm runnung WinXP MS iSCSI 2.06 Initiator, and iscsi-scst. I'm sure I screwed something up here... Running scst vdisk fileio on 512MB file for Default group. This is a @ home project not related to my prior SRPT rantings. Dmesg ------------------- --- CUT --- [26207]: __scst_block_dev:2705:Device BLOCK(new 1), dev ddf4b180 [26207]: scst_alloc_set_UA:2471:Adding new UA to tgt_dev d8eb0000 [26207]: scst_call_dev_task_mgmt_fn:3221:Calling dev handler vdisk task_mgmt_fn(fn=4) [26207]: scst_call_dev_task_mgmt_fn:3225:Dev handler vdisk task_mgmt_fn() returned 1 [26207]: iscsi_task_mgmt_fn_done:2469:req c9a89190, scst_mcmd c1fee2d0, scst status 0 [26207]: iscsi-scst: iscsi_send_task_mgmt_resp:2418:TM req c9a89190 finished, status 0 [26207]: scst_mgmt_cmd_send_done:4009:Target's iscsi task_mgmt_fn_done() returned [26207]: scst_unblock_dev:2738:Device UNBLOCK(new 0), dev ddf4b180 [18736]: scst_inc_on_dev_cmd:2812:cmd c56a3500 (tag 3791650816), blocking further cmds due to serializing (dev ddf4b180) [18736]: __scst_block_dev:2705:Device BLOCK(new 1), dev ddf4b180 [18736]: scst: scst_set_pending_UA:2405:Setting pending UA cmd c56a3500 [18736]: scst_pre_dec_on_dev_cmd:434:cmd c56a3500 (tag 3791650816): unblocking dev ddf4b180 [18736]: scst_unblock_dev:2738:Device UNBLOCK(new 0), dev ddf4b180 [18737]: scst_inc_on_dev_cmd:2812:cmd c56a3500 (tag 3808428032), blocking further cmds due to serializing (dev ddf4b180) [18737]: __scst_block_dev:2705:Device BLOCK(new 1), dev ddf4b180 [18737]: scst_check_sense:1998:Clearing dbl_ua_possible flag [18737]: scst_pre_dec_on_dev_cmd:434:cmd c56a3500 (tag 3808428032): unblocking dev ddf4b180 [18737]: scst_unblock_dev:2738:Device UNBLOCK(new 0), dev ddf4b180 --- END --- |
|
From: Vladislav B. <vs...@vl...> - 2007-12-18 09:59:17
|
Stanley, You didn't provide any performance data. Was it for writes? If so, read "Performance" section in the SCST's README file and use 4K blocks. Vlad Stanley Sufficool wrote: > Ok, gimme a clue here. I've applied all patches to kernel 2.6.22 and > iscsi release patch. I'm runnung WinXP MS iSCSI 2.06 Initiator, and > iscsi-scst. I'm sure I screwed something up here... > > Running scst vdisk fileio on 512MB file for Default group. > > This is a @ home project not related to my prior SRPT rantings. > > Dmesg |
|
From: Stanley S. <sta...@ro...> - 2007-12-19 05:13:53
|
Just connecting to the LUN is resulting in MS iSCSI sending massive amounts of task management target resets. I can forget about even writing to it. I am using 4096 on target and 4096 alloc units on the initiator. modprobe scst modprobe scst_vdisk echo "open disk1 /root/disk1 4096" > /proc/scsi_tgt/vdisk/vdisk echo "add disk1 0" > /proc/scsi_tgt/groups/Default/devices modprobe iscsi_scst [4556]: iscsi-scst: execute_task_management:1625:TM cmd: req cd05b0c8, itt 9d, fn 5, rtt ffffffff [4556]: scst: scst_rx_mgmt_fn:4316:sess=cd05f000, fn 4, tag_set 0, tag 0, lun_set 1, lun=0, cmd_sn_set 0, cmd_sn 0 [4556]: scst_post_rx_mgmt_cmd:4251:Adding mgmt cmd d869e2d0 to active mgmt cmd list [4551]: scst_mgmt_cmd_thread:4148:Deleting mgmt cmd d869e2d0 from active cmd list [4551]: scst: scst_lun_reset:3770:Resetting lun 0 (mcmd d869e2d0) [4551]: __scst_block_dev:2705:Device BLOCK(new 1), dev da458700 [4551]: scst_alloc_set_UA:2471:Adding new UA to tgt_dev cd05d000 [4551]: scst_call_dev_task_mgmt_fn:3221:Calling dev handler vdisk task_mgmt_fn(fn=4) [4551]: scst_call_dev_task_mgmt_fn:3225:Dev handler vdisk task_mgmt_fn() returned 1 [4551]: iscsi_task_mgmt_fn_done:2469:req cd05b0c8, scst_mcmd d869e2d0, scst status 0 [4551]: iscsi-scst: iscsi_send_task_mgmt_resp:2418:TM req cd05b0c8 finished, status 0 [4551]: scst_mgmt_cmd_send_done:4009:Target's iscsi task_mgmt_fn_done() returned [4551]: scst_unblock_dev:2738:Device UNBLOCK(new 0), dev da458700 On Tue, 2007-12-18 at 12:59 +0300, Vladislav Bolkhovitin wrote: > Stanley, > > You didn't provide any performance data. Was it for writes? If so, read > "Performance" section in the SCST's README file and use 4K blocks. > > Vlad > > Stanley Sufficool wrote: > > Ok, gimme a clue here. I've applied all patches to kernel 2.6.22 and > > iscsi release patch. I'm runnung WinXP MS iSCSI 2.06 Initiator, and > > iscsi-scst. I'm sure I screwed something up here... > > > > Running scst vdisk fileio on 512MB file for Default group. > > > > This is a @ home project not related to my prior SRPT rantings. > > > > Dmesg > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Scst-devel mailing list > Scs...@li... > https://lists.sourceforge.net/lists/listinfo/scst-devel |
|
From: Vladislav B. <vs...@vl...> - 2007-12-19 11:29:21
|
Stanley, You again provided too little information. You expect from me to guess too much. I already wrote you that for such issues I need kernel log with timestamps, but you again sent me dmesg output. Should I teach you how to use syslog? Most likely, your problem is in your hardware. Search IET mailing list archive on http://www.nabble.com/iSCSI-Enterprise-Target-f4401.html, it has solutions for many problems like yours. Vlad Stanley Sufficool wrote: > Just connecting to the LUN is resulting in MS iSCSI sending massive > amounts of task management target resets. I can forget about even > writing to it. > > I am using 4096 on target and 4096 alloc units on the initiator. > > modprobe scst > modprobe scst_vdisk > echo "open disk1 /root/disk1 4096" > /proc/scsi_tgt/vdisk/vdisk > echo "add disk1 0" > /proc/scsi_tgt/groups/Default/devices > modprobe iscsi_scst > > [4556]: iscsi-scst: execute_task_management:1625:TM cmd: req cd05b0c8, > itt 9d, fn 5, rtt ffffffff > [4556]: scst: scst_rx_mgmt_fn:4316:sess=cd05f000, fn 4, tag_set 0, tag > 0, lun_set 1, lun=0, cmd_sn_set 0, cmd_sn 0 > [4556]: scst_post_rx_mgmt_cmd:4251:Adding mgmt cmd d869e2d0 to active > mgmt cmd list > [4551]: scst_mgmt_cmd_thread:4148:Deleting mgmt cmd d869e2d0 from active > cmd list > [4551]: scst: scst_lun_reset:3770:Resetting lun 0 (mcmd d869e2d0) > [4551]: __scst_block_dev:2705:Device BLOCK(new 1), dev da458700 > [4551]: scst_alloc_set_UA:2471:Adding new UA to tgt_dev cd05d000 > [4551]: scst_call_dev_task_mgmt_fn:3221:Calling dev handler vdisk > task_mgmt_fn(fn=4) > [4551]: scst_call_dev_task_mgmt_fn:3225:Dev handler vdisk task_mgmt_fn() > returned 1 > [4551]: iscsi_task_mgmt_fn_done:2469:req cd05b0c8, scst_mcmd d869e2d0, > scst status 0 > [4551]: iscsi-scst: iscsi_send_task_mgmt_resp:2418:TM req cd05b0c8 > finished, status 0 > [4551]: scst_mgmt_cmd_send_done:4009:Target's iscsi task_mgmt_fn_done() > returned > [4551]: scst_unblock_dev:2738:Device UNBLOCK(new 0), dev da458700 > > > > > On Tue, 2007-12-18 at 12:59 +0300, Vladislav Bolkhovitin wrote: > >>Stanley, >> >>You didn't provide any performance data. Was it for writes? If so, read >>"Performance" section in the SCST's README file and use 4K blocks. >> >>Vlad >> >>Stanley Sufficool wrote: >> >>>Ok, gimme a clue here. I've applied all patches to kernel 2.6.22 and >>>iscsi release patch. I'm runnung WinXP MS iSCSI 2.06 Initiator, and >>>iscsi-scst. I'm sure I screwed something up here... >>> >>>Running scst vdisk fileio on 512MB file for Default group. >>> >>>This is a @ home project not related to my prior SRPT rantings. >>> >>>Dmesg >> >>------------------------------------------------------------------------- >>SF.Net email is sponsored by: >>Check out the new SourceForge.net Marketplace. >>It's the best place to buy or sell services >>for just about anything Open Source. >>http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >>_______________________________________________ >>Scst-devel mailing list >>Scs...@li... >>https://lists.sourceforge.net/lists/listinfo/scst-devel > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Scst-devel mailing list > Scs...@li... > https://lists.sourceforge.net/lists/listinfo/scst-devel > |
|
From: Stanley S. <sta...@ro...> - 2007-12-21 07:21:57
|
I have recompiled with kernel with debugging and timestamps. I hope this is what you are looking for, if not let me know and I will do whatever is needed to help. I'm still trying to gather debugging info, but now I'm having problems getting iscsi-scst to listen on port 3260. Haven't forgotten about the SRPT corruption issue, the system went production due to time constraints. Now I'm looking for a way to isolate testing. On Wed, 2007-12-19 at 14:29 +0300, Vladislav Bolkhovitin wrote: > Stanley, > > You again provided too little information. You expect from me to guess > too much. I already wrote you that for such issues I need kernel log > with timestamps, but you again sent me dmesg output. Should I teach you > how to use syslog? > > Most likely, your problem is in your hardware. Search IET mailing list > archive on http://www.nabble.com/iSCSI-Enterprise-Target-f4401.html, it > has solutions for many problems like yours. > > Vlad > > Stanley Sufficool wrote: > > Just connecting to the LUN is resulting in MS iSCSI sending massive > > amounts of task management target resets. I can forget about even > > writing to it. > > > > I am using 4096 on target and 4096 alloc units on the initiator. > > > > modprobe scst > > modprobe scst_vdisk > > echo "open disk1 /root/disk1 4096" > /proc/scsi_tgt/vdisk/vdisk > > echo "add disk1 0" > /proc/scsi_tgt/groups/Default/devices > > modprobe iscsi_scst > > > > [4556]: iscsi-scst: execute_task_management:1625:TM cmd: req cd05b0c8, > > itt 9d, fn 5, rtt ffffffff > > [4556]: scst: scst_rx_mgmt_fn:4316:sess=cd05f000, fn 4, tag_set 0, tag > > 0, lun_set 1, lun=0, cmd_sn_set 0, cmd_sn 0 > > [4556]: scst_post_rx_mgmt_cmd:4251:Adding mgmt cmd d869e2d0 to active > > mgmt cmd list > > [4551]: scst_mgmt_cmd_thread:4148:Deleting mgmt cmd d869e2d0 from active > > cmd list > > [4551]: scst: scst_lun_reset:3770:Resetting lun 0 (mcmd d869e2d0) > > [4551]: __scst_block_dev:2705:Device BLOCK(new 1), dev da458700 > > [4551]: scst_alloc_set_UA:2471:Adding new UA to tgt_dev cd05d000 > > [4551]: scst_call_dev_task_mgmt_fn:3221:Calling dev handler vdisk > > task_mgmt_fn(fn=4) > > [4551]: scst_call_dev_task_mgmt_fn:3225:Dev handler vdisk task_mgmt_fn() > > returned 1 > > [4551]: iscsi_task_mgmt_fn_done:2469:req cd05b0c8, scst_mcmd d869e2d0, > > scst status 0 > > [4551]: iscsi-scst: iscsi_send_task_mgmt_resp:2418:TM req cd05b0c8 > > finished, status 0 > > [4551]: scst_mgmt_cmd_send_done:4009:Target's iscsi task_mgmt_fn_done() > > returned > > [4551]: scst_unblock_dev:2738:Device UNBLOCK(new 0), dev da458700 > > > > > > > > > > On Tue, 2007-12-18 at 12:59 +0300, Vladislav Bolkhovitin wrote: > > > >>Stanley, > >> > >>You didn't provide any performance data. Was it for writes? If so, read > >>"Performance" section in the SCST's README file and use 4K blocks. > >> > >>Vlad > >> > >>Stanley Sufficool wrote: > >> > >>>Ok, gimme a clue here. I've applied all patches to kernel 2.6.22 and > >>>iscsi release patch. I'm runnung WinXP MS iSCSI 2.06 Initiator, and > >>>iscsi-scst. I'm sure I screwed something up here... > >>> > >>>Running scst vdisk fileio on 512MB file for Default group. > >>> > >>>This is a @ home project not related to my prior SRPT rantings. > >>> > >>>Dmesg > >> > >>------------------------------------------------------------------------- > >>SF.Net email is sponsored by: > >>Check out the new SourceForge.net Marketplace. > >>It's the best place to buy or sell services > >>for just about anything Open Source. > >>http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > >>_______________________________________________ > >>Scst-devel mailing list > >>Scs...@li... > >>https://lists.sourceforge.net/lists/listinfo/scst-devel > > > > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services > > for just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > _______________________________________________ > > Scst-devel mailing list > > Scs...@li... > > https://lists.sourceforge.net/lists/listinfo/scst-devel > > > |
|
From: Vladislav B. <vs...@vl...> - 2007-12-21 10:27:18
|
Stanley Sufficool wrote: > I have recompiled with kernel with debugging and timestamps. I meant timestamps set by syslogd. Kernel's timestamps are OK too, but dmesg buffer is often too small to keep all the necessary messages. > I hope this > is what you are looking for, if not let me know and I will do whatever > is needed to help. You don't provide any logs. Did you forget to attach them? > I'm still trying to gather debugging info, but now I'm having problems > getting iscsi-scst to listen on port 3260. What's the error? > Haven't forgotten about the SRPT corruption issue, the system went > production due to time constraints. Now I'm looking for a way to isolate > testing. |
|
From: Stanley S. <sta...@ro...> - 2007-12-22 04:55:13
Attachments:
syslog.txt
|
Recompiled and fixed my config file error which cause iscsi-scstd to quit without error. I had a leading slash on a config line, should iscsi-scstd report errors in config file? Anyway, everything looks good... except when I try a full format on the 512MB lun. Attached is output from syslog-ng. A "quick" format returns OK with an operable volume. I run the SQLIO sim tool to stress test and it completes without errors after 2GB read / 1 GB written. So I'm not sure what's so different about a full format from MS iSCSI 2.06 vs read/write except the first 512 bytes of the disk. On Fri, 2007-12-21 at 13:26 +0300, Vladislav Bolkhovitin wrote: > Stanley Sufficool wrote: > > I have recompiled with kernel with debugging and timestamps. > > I meant timestamps set by syslogd. Kernel's timestamps are OK too, but > dmesg buffer is often too small to keep all the necessary messages. > > > I hope this > > is what you are looking for, if not let me know and I will do whatever > > is needed to help. > > You don't provide any logs. Did you forget to attach them? > > > I'm still trying to gather debugging info, but now I'm having problems > > getting iscsi-scst to listen on port 3260. > > What's the error? > > > Haven't forgotten about the SRPT corruption issue, the system went > > production due to time constraints. Now I'm looking for a way to isolate > > testing. |
|
From: Vladislav B. <vs...@vl...> - 2007-12-24 19:24:55
|
Stanley Sufficool wrote: > Recompiled and fixed my config file error which cause iscsi-scstd to > quit without error. I had a leading slash on a config line, should > iscsi-scstd report errors in config file? Yes, it should. Can you provide more details, so I'll be able to fix it? > Anyway, everything looks good... except when I try a full format on the > 512MB lun. Attached is output from syslog-ng. A "quick" format returns > OK with an operable volume. Good! > I run the SQLIO sim tool to stress test and it completes without errors > after 2GB read / 1 GB written. So I'm not sure what's so different about > a full format from MS iSCSI 2.06 vs read/write except the first 512 > bytes of the disk. Seems, the VERIFY commands handling was broken by one of the previous commits. Try with the latest code. > On Fri, 2007-12-21 at 13:26 +0300, Vladislav Bolkhovitin wrote: > >>Stanley Sufficool wrote: >> >>>I have recompiled with kernel with debugging and timestamps. >> >>I meant timestamps set by syslogd. Kernel's timestamps are OK too, but >>dmesg buffer is often too small to keep all the necessary messages. >> >> >>>I hope this >>>is what you are looking for, if not let me know and I will do whatever >>>is needed to help. >> >>You don't provide any logs. Did you forget to attach them? >> >> >>>I'm still trying to gather debugging info, but now I'm having problems >>>getting iscsi-scst to listen on port 3260. >> >>What's the error? >> >> >>>Haven't forgotten about the SRPT corruption issue, the system went >>>production due to time constraints. Now I'm looking for a way to isolate >>>testing. |
|
From: Stanley S. <sta...@ro...> - 2007-12-25 04:23:57
Attachments:
syslog
|
Actually, iscsi-scst conf DOES report error with preceding slash. It reports via syslog but not dmesg (which is where I was first looking). I retried with the latest code and I'm afraid I'm back to the original problem, very slow response and many target reset requests from MS iSCSI 2.06. Attached is a hopefully usable syslog. On Mon, 2007-12-24 at 22:25 +0300, Vladislav Bolkhovitin wrote: > Stanley Sufficool wrote: > > Recompiled and fixed my config file error which cause iscsi-scstd to > > quit without error. I had a leading slash on a config line, should > > iscsi-scstd report errors in config file? > > Yes, it should. Can you provide more details, so I'll be able to fix it? > > > Anyway, everything looks good... except when I try a full format on the > > 512MB lun. Attached is output from syslog-ng. A "quick" format returns > > OK with an operable volume. > > Good! > > > I run the SQLIO sim tool to stress test and it completes without errors > > after 2GB read / 1 GB written. So I'm not sure what's so different about > > a full format from MS iSCSI 2.06 vs read/write except the first 512 > > bytes of the disk. > > Seems, the VERIFY commands handling was broken by one of the previous > commits. Try with the latest code. > > > On Fri, 2007-12-21 at 13:26 +0300, Vladislav Bolkhovitin wrote: > > > >>Stanley Sufficool wrote: > >> > >>>I have recompiled with kernel with debugging and timestamps. > >> > >>I meant timestamps set by syslogd. Kernel's timestamps are OK too, but > >>dmesg buffer is often too small to keep all the necessary messages. > >> > >> > >>>I hope this > >>>is what you are looking for, if not let me know and I will do whatever > >>>is needed to help. > >> > >>You don't provide any logs. Did you forget to attach them? > >> > >> > >>>I'm still trying to gather debugging info, but now I'm having problems > >>>getting iscsi-scst to listen on port 3260. > >> > >>What's the error? > >> > >> > >>>Haven't forgotten about the SRPT corruption issue, the system went > >>>production due to time constraints. Now I'm looking for a way to isolate > >>>testing. |
|
From: Vladislav B. <vs...@vl...> - 2007-12-25 12:23:11
|
Stanley Sufficool wrote: > Actually, iscsi-scst conf DOES report error with preceding slash. It > reports via syslog but not dmesg (which is where I was first looking). > > I retried with the latest code and I'm afraid I'm back to the original > problem, very slow response and many target reset requests from MS iSCSI > 2.06. It seems I was right and 99% you have a problem somewhere in your network hardware, like you use 9K MTU, but your switch doesn't support it. What is your hardware/software configuration? Have you checked IET mailing list as I suggested? Have you tested your network under full high load using your favorite network testing or performance measurement tool? It would be interesting also if you reproduce it with SCSI logging enableb by: # echo "add scsi" >/proc/scsi_tgt/trace_level > Attached is a hopefully usable syslog. Yes, it is good > On Mon, 2007-12-24 at 22:25 +0300, Vladislav Bolkhovitin wrote: > >>Stanley Sufficool wrote: >> >>>Recompiled and fixed my config file error which cause iscsi-scstd to >>>quit without error. I had a leading slash on a config line, should >>>iscsi-scstd report errors in config file? >> >>Yes, it should. Can you provide more details, so I'll be able to fix it? >> >> >>>Anyway, everything looks good... except when I try a full format on the >>>512MB lun. Attached is output from syslog-ng. A "quick" format returns >>>OK with an operable volume. >> >>Good! >> >> >>>I run the SQLIO sim tool to stress test and it completes without errors >>>after 2GB read / 1 GB written. So I'm not sure what's so different about >>>a full format from MS iSCSI 2.06 vs read/write except the first 512 >>>bytes of the disk. >> >>Seems, the VERIFY commands handling was broken by one of the previous >>commits. Try with the latest code. >> >> >>>On Fri, 2007-12-21 at 13:26 +0300, Vladislav Bolkhovitin wrote: >>> >>> >>>>Stanley Sufficool wrote: >>>> >>>> >>>>>I have recompiled with kernel with debugging and timestamps. >>>> >>>>I meant timestamps set by syslogd. Kernel's timestamps are OK too, but >>>>dmesg buffer is often too small to keep all the necessary messages. >>>> >>>> >>>> >>>>>I hope this >>>>>is what you are looking for, if not let me know and I will do whatever >>>>>is needed to help. >>>> >>>>You don't provide any logs. Did you forget to attach them? >>>> >>>> >>>> >>>>>I'm still trying to gather debugging info, but now I'm having problems >>>>>getting iscsi-scst to listen on port 3260. >>>> >>>>What's the error? |
|
From: Stanley S. <sta...@ro...> - 2007-12-30 06:21:27
Attachments:
syslog2.gz
|
--- iSCSI -- Target uses max of 1500 MTU. Initiator uses the MS default for the adapter, which I think is 1480. I'm running crappy hardware (At home anyways). Target is Gentoo Linux 2.6.23 on AMD Sempron 2100+ Socket A, 1GB RAM, 100 MBit Eth, 250 GB 7200 RPM PATA. Initiator is Presario 2100 Laptop / AMD Athlon XP 1800+, 512 MB RAM 100 Mbit Eth, MS XP Home. I obviously didn't get my Christmas wish. Re-ran with the scsi tracing, and got the attached. ---- SRPT ---- FYI, preliminary testing with SRPT is showing outstanding commands in SCST after the initiator ejects the target (ib_srpt). I will have more on this on/after Wednesday when I have a chance to further test Vu's suggestions with single threading and module parameters for forcing sgv usage. BTW, at work hardware isn't as shoddy: 2each HP MSA60 shelves using P800 raid (LSI Logic Chips) w/ 12each 250 GB SATA each, Dual Port 4x Infiniband interconnect. Currently running IET on AMD Opteron dual core Gentoo Linux 2.6.23. I want to run SRPT or at least iSCSI-SCST. But IET (iSCSI over 10Gbit IPoIB) is stable for now. --- Happy New Years --- On Tue, 2007-12-25 at 15:23 +0300, Vladislav Bolkhovitin wrote: > Stanley Sufficool wrote: > > Actually, iscsi-scst conf DOES report error with preceding slash. It > > reports via syslog but not dmesg (which is where I was first looking). > > > > I retried with the latest code and I'm afraid I'm back to the original > > problem, very slow response and many target reset requests from MS iSCSI > > 2.06. > > It seems I was right and 99% you have a problem somewhere in your > network hardware, like you use 9K MTU, but your switch doesn't support it. > > What is your hardware/software configuration? > > Have you checked IET mailing list as I suggested? > > Have you tested your network under full high load using your favorite > network testing or performance measurement tool? > > It would be interesting also if you reproduce it with SCSI logging > enableb by: > > # echo "add scsi" >/proc/scsi_tgt/trace_level > > > Attached is a hopefully usable syslog. > > Yes, it is good > > > On Mon, 2007-12-24 at 22:25 +0300, Vladislav Bolkhovitin wrote: > > > >>Stanley Sufficool wrote: > >> > >>>Recompiled and fixed my config file error which cause iscsi-scstd to > >>>quit without error. I had a leading slash on a config line, should > >>>iscsi-scstd report errors in config file? > >> > >>Yes, it should. Can you provide more details, so I'll be able to fix it? > >> > >> > >>>Anyway, everything looks good... except when I try a full format on the > >>>512MB lun. Attached is output from syslog-ng. A "quick" format returns > >>>OK with an operable volume. > >> > >>Good! > >> > >> > >>>I run the SQLIO sim tool to stress test and it completes without errors > >>>after 2GB read / 1 GB written. So I'm not sure what's so different about > >>>a full format from MS iSCSI 2.06 vs read/write except the first 512 > >>>bytes of the disk. > >> > >>Seems, the VERIFY commands handling was broken by one of the previous > >>commits. Try with the latest code. > >> > >> > >>>On Fri, 2007-12-21 at 13:26 +0300, Vladislav Bolkhovitin wrote: > >>> > >>> > >>>>Stanley Sufficool wrote: > >>>> > >>>> > >>>>>I have recompiled with kernel with debugging and timestamps. > >>>> > >>>>I meant timestamps set by syslogd. Kernel's timestamps are OK too, but > >>>>dmesg buffer is often too small to keep all the necessary messages. > >>>> > >>>> > >>>> > >>>>>I hope this > >>>>>is what you are looking for, if not let me know and I will do whatever > >>>>>is needed to help. > >>>> > >>>>You don't provide any logs. Did you forget to attach them? > >>>> > >>>> > >>>> > >>>>>I'm still trying to gather debugging info, but now I'm having problems > >>>>>getting iscsi-scst to listen on port 3260. > >>>> > >>>>What's the error? > |
|
From: Vladislav B. <vs...@vl...> - 2007-12-31 12:14:57
|
Stanley Sufficool wrote: > --- iSCSI -- > > Target uses max of 1500 MTU. Initiator uses the MS default for the > adapter, which I think is 1480. If you have different MTUs anywhere on the participating hosts, you can have exactly your problems (small packets go, big one - don't), if there is a "black hole" router on the route. Google for details. > I'm running crappy hardware (At home anyways). Target is Gentoo Linux > 2.6.23 on AMD Sempron 2100+ Socket A, 1GB RAM, 100 MBit Eth, 250 GB 7200 > RPM PATA. Initiator is Presario 2100 Laptop / AMD Athlon XP 1800+, 512 > MB RAM 100 Mbit Eth, MS XP Home. I obviously didn't get my Christmas > wish. > > Re-ran with the scsi tracing, and got the attached. From your log everything works fine, so, if there is any problem with iSCSI-SCST I can't see it there. Have you tested your network with any net testing tools? > ---- SRPT ---- > > FYI, preliminary testing with SRPT is showing outstanding commands in > SCST after the initiator ejects the target (ib_srpt). I will have more > on this on/after Wednesday when I have a chance to further test Vu's > suggestions with single threading and module parameters for forcing sgv > usage. > > BTW, at work hardware isn't as shoddy: > 2each HP MSA60 shelves using P800 raid (LSI Logic Chips) w/ 12each 250 > GB SATA each, Dual Port 4x Infiniband interconnect. Currently running > IET on AMD Opteron dual core Gentoo Linux 2.6.23. I want to run SRPT or > at least iSCSI-SCST. But IET (iSCSI over 10Gbit IPoIB) is stable for > now. Have you tried iSCSI-SCST here? What's the performance (in the release mode)? I think you should CC to Vu on any Infiniband related messages. > --- Happy New Years --- Happy New Year! > On Tue, 2007-12-25 at 15:23 +0300, Vladislav Bolkhovitin wrote: > >>Stanley Sufficool wrote: >> >>>Actually, iscsi-scst conf DOES report error with preceding slash. It >>>reports via syslog but not dmesg (which is where I was first looking). >>> >>>I retried with the latest code and I'm afraid I'm back to the original >>>problem, very slow response and many target reset requests from MS iSCSI >>>2.06. >> >>It seems I was right and 99% you have a problem somewhere in your >>network hardware, like you use 9K MTU, but your switch doesn't support it. >> >>What is your hardware/software configuration? >> >>Have you checked IET mailing list as I suggested? >> >>Have you tested your network under full high load using your favorite >>network testing or performance measurement tool? >> >>It would be interesting also if you reproduce it with SCSI logging >>enableb by: >> >># echo "add scsi" >/proc/scsi_tgt/trace_level >> >> >>>Attached is a hopefully usable syslog. >> >>Yes, it is good >> >> >>>On Mon, 2007-12-24 at 22:25 +0300, Vladislav Bolkhovitin wrote: >>> >>> >>>>Stanley Sufficool wrote: >>>> >>>> >>>>>Recompiled and fixed my config file error which cause iscsi-scstd to >>>>>quit without error. I had a leading slash on a config line, should >>>>>iscsi-scstd report errors in config file? >>>> >>>>Yes, it should. Can you provide more details, so I'll be able to fix it? >>>> >>>> >>>> >>>>>Anyway, everything looks good... except when I try a full format on the >>>>>512MB lun. Attached is output from syslog-ng. A "quick" format returns >>>>>OK with an operable volume. >>>> >>>>Good! >>>> >>>> >>>> >>>>>I run the SQLIO sim tool to stress test and it completes without errors >>>>>after 2GB read / 1 GB written. So I'm not sure what's so different about >>>>>a full format from MS iSCSI 2.06 vs read/write except the first 512 >>>>>bytes of the disk. >>>> >>>>Seems, the VERIFY commands handling was broken by one of the previous >>>>commits. Try with the latest code. >>>> >>>> >>>> >>>>>On Fri, 2007-12-21 at 13:26 +0300, Vladislav Bolkhovitin wrote: >>>>> >>>>> >>>>> >>>>>>Stanley Sufficool wrote: >>>>>> >>>>>> >>>>>> >>>>>>>I have recompiled with kernel with debugging and timestamps. >>>>>> >>>>>>I meant timestamps set by syslogd. Kernel's timestamps are OK too, but >>>>>>dmesg buffer is often too small to keep all the necessary messages. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>I hope this >>>>>>>is what you are looking for, if not let me know and I will do whatever >>>>>>>is needed to help. >>>>>> >>>>>>You don't provide any logs. Did you forget to attach them? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>I'm still trying to gather debugging info, but now I'm having problems >>>>>>>getting iscsi-scst to listen on port 3260. >>>>>> >>>>>>What's the error? >> |
|
From: Stanley S. <sta...@ro...> - 2008-01-19 03:07:30
|
On Mon, 2007-12-31 at 15:15 +0300, Vladislav Bolkhovitin wrote: > Stanley Sufficool wrote: > > --- iSCSI -- > > > > Target uses max of 1500 MTU. Initiator uses the MS default for the > > adapter, which I think is 1480. > > If you have different MTUs anywhere on the participating hosts, you can > have exactly your problems (small packets go, big one - don't), if there > is a "black hole" router on the route. Google for details. > You are exactly right. Fixed the MTUs to match and all runs just fine now. Thanks! > > I'm running crappy hardware (At home anyways). Target is Gentoo Linux > > 2.6.23 on AMD Sempron 2100+ Socket A, 1GB RAM, 100 MBit Eth, 250 GB 7200 > > RPM PATA. Initiator is Presario 2100 Laptop / AMD Athlon XP 1800+, 512 > > MB RAM 100 Mbit Eth, MS XP Home. I obviously didn't get my Christmas > > wish. > > > > Re-ran with the scsi tracing, and got the attached. > > From your log everything works fine, so, if there is any problem with > iSCSI-SCST I can't see it there. > > Have you tested your network with any net testing tools? > > > ---- SRPT ---- > > > > FYI, preliminary testing with SRPT is showing outstanding commands in > > SCST after the initiator ejects the target (ib_srpt). I will have more > > on this on/after Wednesday when I have a chance to further test Vu's > > suggestions with single threading and module parameters for forcing sgv > > usage. > > > > BTW, at work hardware isn't as shoddy: > > 2each HP MSA60 shelves using P800 raid (LSI Logic Chips) w/ 12each 250 > > GB SATA each, Dual Port 4x Infiniband interconnect. Currently running > > IET on AMD Opteron dual core Gentoo Linux 2.6.23. I want to run SRPT or > > at least iSCSI-SCST. But IET (iSCSI over 10Gbit IPoIB) is stable for > > now. > > Have you tried iSCSI-SCST here? What's the performance (in the release > mode)? > > I think you should CC to Vu on any Infiniband related messages. > > > --- Happy New Years --- > > Happy New Year! > > > On Tue, 2007-12-25 at 15:23 +0300, Vladislav Bolkhovitin wrote: > > > >>Stanley Sufficool wrote: > >> > >>>Actually, iscsi-scst conf DOES report error with preceding slash. It > >>>reports via syslog but not dmesg (which is where I was first looking). > >>> > >>>I retried with the latest code and I'm afraid I'm back to the original > >>>problem, very slow response and many target reset requests from MS iSCSI > >>>2.06. > >> > >>It seems I was right and 99% you have a problem somewhere in your > >>network hardware, like you use 9K MTU, but your switch doesn't support it. > >> > >>What is your hardware/software configuration? > >> > >>Have you checked IET mailing list as I suggested? > >> > >>Have you tested your network under full high load using your favorite > >>network testing or performance measurement tool? > >> > >>It would be interesting also if you reproduce it with SCSI logging > >>enableb by: > >> > >># echo "add scsi" >/proc/scsi_tgt/trace_level > >> > >> > >>>Attached is a hopefully usable syslog. > >> > >>Yes, it is good > >> > >> > >>>On Mon, 2007-12-24 at 22:25 +0300, Vladislav Bolkhovitin wrote: > >>> > >>> > >>>>Stanley Sufficool wrote: > >>>> > >>>> > >>>>>Recompiled and fixed my config file error which cause iscsi-scstd to > >>>>>quit without error. I had a leading slash on a config line, should > >>>>>iscsi-scstd report errors in config file? > >>>> > >>>>Yes, it should. Can you provide more details, so I'll be able to fix it? > >>>> > >>>> > >>>> > >>>>>Anyway, everything looks good... except when I try a full format on the > >>>>>512MB lun. Attached is output from syslog-ng. A "quick" format returns > >>>>>OK with an operable volume. > >>>> > >>>>Good! > >>>> > >>>> > >>>> > >>>>>I run the SQLIO sim tool to stress test and it completes without errors > >>>>>after 2GB read / 1 GB written. So I'm not sure what's so different about > >>>>>a full format from MS iSCSI 2.06 vs read/write except the first 512 > >>>>>bytes of the disk. > >>>> > >>>>Seems, the VERIFY commands handling was broken by one of the previous > >>>>commits. Try with the latest code. > >>>> > >>>> > >>>> > >>>>>On Fri, 2007-12-21 at 13:26 +0300, Vladislav Bolkhovitin wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Stanley Sufficool wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>I have recompiled with kernel with debugging and timestamps. > >>>>>> > >>>>>>I meant timestamps set by syslogd. Kernel's timestamps are OK too, but > >>>>>>dmesg buffer is often too small to keep all the necessary messages. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>I hope this > >>>>>>>is what you are looking for, if not let me know and I will do whatever > >>>>>>>is needed to help. > >>>>>> > >>>>>>You don't provide any logs. Did you forget to attach them? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>I'm still trying to gather debugging info, but now I'm having problems > >>>>>>>getting iscsi-scst to listen on port 3260. > >>>>>> > >>>>>>What's the error? > >> > |
Thanks for helping keep SourceForge clean.
X