You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(35) |
Oct
(73) |
Nov
(37) |
Dec
(60) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(76) |
Feb
(301) |
Mar
(123) |
Apr
(29) |
May
(61) |
Jun
(45) |
Jul
(10) |
Aug
(63) |
Sep
(17) |
Oct
(28) |
Nov
(43) |
Dec
(60) |
2007 |
Jan
(71) |
Feb
(86) |
Mar
(20) |
Apr
|
May
(73) |
Jun
(67) |
Jul
(40) |
Aug
(67) |
Sep
(30) |
Oct
(38) |
Nov
(113) |
Dec
(159) |
2008 |
Jan
(208) |
Feb
(299) |
Mar
(105) |
Apr
(64) |
May
(328) |
Jun
(135) |
Jul
(221) |
Aug
(119) |
Sep
(132) |
Oct
(293) |
Nov
(180) |
Dec
(225) |
2009 |
Jan
(136) |
Feb
(161) |
Mar
(226) |
Apr
(363) |
May
(188) |
Jun
(269) |
Jul
(297) |
Aug
(141) |
Sep
(237) |
Oct
(191) |
Nov
(137) |
Dec
(211) |
2010 |
Jan
(141) |
Feb
(234) |
Mar
(254) |
Apr
(370) |
May
(215) |
Jun
(211) |
Jul
(199) |
Aug
(234) |
Sep
(294) |
Oct
(182) |
Nov
(197) |
Dec
(263) |
2011 |
Jan
(115) |
Feb
(135) |
Mar
(114) |
Apr
(177) |
May
(181) |
Jun
(116) |
Jul
(230) |
Aug
(166) |
Sep
(93) |
Oct
(119) |
Nov
(104) |
Dec
(146) |
2012 |
Jan
(138) |
Feb
(182) |
Mar
(190) |
Apr
(126) |
May
(131) |
Jun
(92) |
Jul
(103) |
Aug
(74) |
Sep
(41) |
Oct
(65) |
Nov
(90) |
Dec
(97) |
2013 |
Jan
(73) |
Feb
(80) |
Mar
(152) |
Apr
(93) |
May
(96) |
Jun
(49) |
Jul
(73) |
Aug
(72) |
Sep
(86) |
Oct
(115) |
Nov
(80) |
Dec
(61) |
2014 |
Jan
(115) |
Feb
(171) |
Mar
(191) |
Apr
(150) |
May
(51) |
Jun
(117) |
Jul
(131) |
Aug
(91) |
Sep
(92) |
Oct
(101) |
Nov
(62) |
Dec
(108) |
2015 |
Jan
(118) |
Feb
(58) |
Mar
(79) |
Apr
(99) |
May
(64) |
Jun
(95) |
Jul
(69) |
Aug
(74) |
Sep
(77) |
Oct
(94) |
Nov
(118) |
Dec
(50) |
2016 |
Jan
(47) |
Feb
(137) |
Mar
(159) |
Apr
(50) |
May
(45) |
Jun
(77) |
Jul
(63) |
Aug
(80) |
Sep
(58) |
Oct
(49) |
Nov
(28) |
Dec
(46) |
2017 |
Jan
(34) |
Feb
(36) |
Mar
(108) |
Apr
(127) |
May
(73) |
Jun
(90) |
Jul
(28) |
Aug
(39) |
Sep
(51) |
Oct
(60) |
Nov
(32) |
Dec
(57) |
2018 |
Jan
(73) |
Feb
(19) |
Mar
(32) |
Apr
(52) |
May
(42) |
Jun
(35) |
Jul
(50) |
Aug
(21) |
Sep
(19) |
Oct
(24) |
Nov
(47) |
Dec
(35) |
2019 |
Jan
(37) |
Feb
(51) |
Mar
(59) |
Apr
(44) |
May
(42) |
Jun
(36) |
Jul
(15) |
Aug
(3) |
Sep
(36) |
Oct
(44) |
Nov
(29) |
Dec
(14) |
2020 |
Jan
(16) |
Feb
(20) |
Mar
(10) |
Apr
(13) |
May
(49) |
Jun
(15) |
Jul
(37) |
Aug
(37) |
Sep
(11) |
Oct
(13) |
Nov
(49) |
Dec
(25) |
2021 |
Jan
(23) |
Feb
(12) |
Mar
(15) |
Apr
(15) |
May
(10) |
Jun
(17) |
Jul
(9) |
Aug
(39) |
Sep
(55) |
Oct
(25) |
Nov
(30) |
Dec
(17) |
2022 |
Jan
(10) |
Feb
(14) |
Mar
(1) |
Apr
(4) |
May
(34) |
Jun
(2) |
Jul
(13) |
Aug
(7) |
Sep
(2) |
Oct
(11) |
Nov
(2) |
Dec
(5) |
2023 |
Jan
(4) |
Feb
(7) |
Mar
(4) |
Apr
|
May
|
Jun
(10) |
Jul
(1) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
2024 |
Jan
(8) |
Feb
(2) |
Mar
(6) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Bart V. A. <bar...@gm...> - 2008-02-22 15:06:35
|
Hello, I'm trying to let the iSCSI initiator of OpenSolaris build 82 communicate with SCST. The following errors appear in the kernel log of the target when running the format command on the initiator system: dev_vdisk: ***ERROR*** MODE SELECT: PF and/or SP are wrongly set (cdb[1]=1) scst: Warning: expected transfer length 4 for opcode 0x04 (handler vdisk, target iscsi) doesn't match decoded value 0. Faulty initiator (e.g. VMware is known to be such) or scst_scsi_op_table should be updated? iscsi-scst: ***ERROR*** Unexpected unsolicited data (ITT c6030000 CDB 4 scst: Warning: expected transfer length 4 for opcode 0x04 (handler vdisk, target iscsi) doesn't match decoded value 0. Faulty initiator (e.g. VMware is known to be such) or scst_scsi_op_table should be updated? To which SCSI commands do these messages apply ? I have captured the iSCSI communication via Wireshark and would like to verify the commands sent by the initiator. Bart. |
From: Bart V. A. <bar...@gm...> - 2008-02-22 14:41:16
|
On Wed, Jan 23, 2008 at 8:05 AM, Bart Van Assche <bar...@gm...> wrote: > On Jan 21, 2008 3:20 PM, Vladislav Bolkhovitin <vs...@vl...> wrote: > > > See description of PERSISTENT RESERVE IN and PERSISTENT RESERVE OUT SCSI > > commands. > > > > Seems, now we've reached the point when you should ask OpenSolaris > > people. Something like send them the same trace and ask why it doesn't > > work and if support for persistent reservations is required from target > > in your setup. CC this mailing list, please. > > I have reported this issue in the OpenSolaris bug database. I will > post the bug number as soon as the bug report is made publicly > accessible. The entry I filed in the OpenSolaris bug database is still not publically available, but this works now with OpenSolaris build 82. Bart Van Assche. |
From: Daniel F. <dfe...@ho...> - 2008-02-22 14:14:36
|
Hi Stanislaw, i start testing the new driver and still having problems from Windows initiators. I connect a windows Initiator to SCST/QLA_ISP and Windows see disk on LDM, i initialize disk, the try format and after wait 1~ min, give me a error say "format cannot complete", i check device manager and the disk have disappeared! SCST/QLA_ISP Log: Feb 22 12:58:56 SuperStor kernel: dev_vdisk: Attached SCSI target virtual disk FCDISK1 (file="/dev/CUME/FCDISK1", fs=102400MB, bs=4096, nblocks=26214400, cyln=12800) Feb 22 12:58:56 SuperStor kernel: scst: Attached SCSI target mid-level to virtual device FCDISK1 (id 2) Feb 22 12:59:47 SuperStor kernel: scst: Added device FCDISK1 to group Default Feb 22 13:02:10 SuperStor kernel: scst: Added name 21:00:00:e0:8b:9b:b7:d0 to group Default Feb 22 13:03:02 SuperStor kernel: isp0: Board Type 2422, Chip Revision 0x3, resident F/W Revision 4.0.22 Feb 22 13:03:02 SuperStor kernel: isp0: 4096 max I/O command limit set Feb 22 13:03:02 SuperStor kernel: isp0: Chan 0 0x0000000000000000/0x2100001b3208f81a Role Target Feb 22 13:03:02 SuperStor kernel: isp0: All luns now enabled for target mode on channel 0 Feb 22 13:03:04 SuperStor kernel: isp0: Chan 0 Loop Reset Received Feb 22 13:03:04 SuperStor kernel: isp0: LIP Received Feb 22 13:03:04 SuperStor kernel: isp0: Chan 0 Loop UP Feb 22 13:03:04 SuperStor kernel: isp0: s/w notify code 1008 acked Feb 22 13:03:04 SuperStor kernel: isp0: Chan 0 Port Database Changed, N-Port Handle 0xffff nlstate 6 reason 0x00 Feb 22 13:03:04 SuperStor kernel: isp0: Chan 0 Loop Reset Received Feb 22 13:03:04 SuperStor kernel: isp0: Chan 0 Firmware State Waiting for AL_PA> Feb 22 13:03:04 SuperStor kernel: isp0: LIP Received Feb 22 13:03:04 SuperStor kernel: isp0: Chan 0 Firmware State Wait Login> Feb 22 13:03:04 SuperStor kernel: isp0: Chan 0 Port Database Changed, N-Port Handle 0xffff nlstate 6 reason 0x00 Feb 22 13:03:04 SuperStor kernel: isp0: Chan 0 Firmware State Ready> Feb 22 13:03:04 SuperStor kernel: isp0: Chan 0 2Gb link speed Feb 22 13:03:04 SuperStor kernel: isp0: Chan 0 WWPN 0x2100001b3208f81a PortID 0x0000ef N-Port Handle 0, Connection 'Private Loop' Feb 22 13:03:04 SuperStor kernel: isp0: Chan 0 Port Database Changed, N-Port Handle 0x0000 nlstate 7 reason 0x17 Feb 22 13:03:04 SuperStor kernel: isp0: cannot find WWN for N-port handle 0x0 for ABORT TASK Feb 22 13:03:04 SuperStor kernel: isp0: Chan 0 Port Database Changed, N-Port Handle 0x0000 nlstate 4 reason 0x06 Feb 22 13:39:19 SuperStor kernel: isp0: Chan 0 Loop Reset Received Feb 22 13:39:19 SuperStor kernel: isp0: LIP Received Feb 22 13:39:21 SuperStor kernel: isp0: Chan 0 Port Database Changed, N-Port Handle 0xffff nlstate 6 reason 0x00 Feb 22 13:39:21 SuperStor kernel: isp0: Chan 0 Firmware State Ready> Feb 22 13:39:21 SuperStor kernel: isp0: Chan 0 2Gb link speed Feb 22 13:39:21 SuperStor kernel: isp0: Chan 0 WWPN 0x2100001b3208f81a PortID 0x0000ef N-Port Handle 0, Connection 'Private Loop' Feb 22 13:39:21 SuperStor kernel: isp0: PORT LOGOUT [ffffffff] from 0x0000000000000000 Feb 22 13:39:47 SuperStor kernel: isp0: Chan 0 Loop Reset Received Feb 22 13:39:47 SuperStor kernel: isp0: LIP Received Feb 22 13:39:47 SuperStor kernel: isp0: Chan 0 Port Database Changed, N-Port Handle 0xffff nlstate 6 reason 0x00 Feb 22 13:39:47 SuperStor kernel: isp0: Chan 0 Firmware State Ready> Feb 22 13:39:47 SuperStor kernel: isp0: Chan 0 Port Database Changed, N-Port Handle 0x0000 nlstate 4 reason 0x06 Feb 22 13:39:47 SuperStor kernel: isp0: Chan 0 2Gb link speed Feb 22 13:39:47 SuperStor kernel: isp0: Chan 0 WWPN 0x2100001b3208f81a PortID 0x0000ef N-Port Handle 0, Connection 'Private Loop' Feb 22 13:39:47 SuperStor kernel: scst: Using security group "Default" for initiator "21:00:00:e0:8b:9b:b7:d0" Feb 22 13:40:46 SuperStor kernel: isp0: ABTS RSP response[0x10fcd4]: status=0x31 sub=(0x1b 0xe8) Feb 22 13:40:46 SuperStor kernel: isp0: termination of 0x10fcd4 complete Feb 22 13:40:54 SuperStor kernel: isp0: Chan 0 Port Database Changed, N-Port Handle 0x0000 nlstate 7 reason 0x0b Feb 22 13:43:58 SuperStor kernel: isp0: Chan 0 Loop DOWN Feb 22 13:43:58 SuperStor kernel: isp0: s/w notify code 1009 acked Feb 22 13:44:10 SuperStor kernel: isp0: Chan 0 Loop Reset Received Feb 22 13:44:10 SuperStor kernel: isp0: LIP Received Feb 22 13:44:10 SuperStor kernel: isp0: Chan 0 Loop UP Feb 22 13:44:10 SuperStor kernel: isp0: s/w notify code 1008 acked Feb 22 13:44:10 SuperStor kernel: isp0: Chan 0 Port Database Changed, N-Port Handle 0xffff nlstate 6 reason 0x00 Feb 22 13:44:10 SuperStor kernel: isp0: Chan 0 Port Database Changed, N-Port Handle 0x0000 nlstate 4 reason 0x06 Feb 22 13:44:10 SuperStor kernel: isp0: Chan 0 Firmware State Ready> Feb 22 13:44:10 SuperStor kernel: isp0: Chan 0 4Gb link speed Feb 22 13:44:10 SuperStor kernel: isp0: Chan 0 WWPN 0x2100001b3208f81a PortID 0x0000ef N-Port Handle 0, Connection 'Private Loop' Feb 22 13:44:15 SuperStor kernel: scst: Warning: expected transfer length 16 for opcode 0x25 (handler vdisk_blk, target qla_isp) doesn't match decoded value 8. Faulty initiator (e.g. VMware is known to be such) or scst_scsi_op_table should be updated? Feb 22 13:46:17 SuperStor kernel: e1000: eth1: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 22 13:46:17 SuperStor kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready Feb 22 13:46:17 SuperStor kernel: bonding: bond0: link status definitely up for interface eth1. Feb 22 13:46:33 SuperStor kernel: isp0: Chan 0 Port Database Changed, N-Port Handle 0x0000 nlstate 7 reason 0x0b Feb 22 13:47:21 SuperStor kernel: isp0: Chan 0 Loop DOWN Feb 22 13:47:21 SuperStor kernel: isp0: s/w notify code 1009 acked Feb 22 13:47:27 SuperStor kernel: isp0: Chan 0 Loop Reset Received Feb 22 13:47:27 SuperStor kernel: isp0: LIP Received Feb 22 13:47:27 SuperStor kernel: isp0: s/w notify code 1008 acked Feb 22 13:47:40 SuperStor kernel: isp0: Chan 0 Loop Reset Received Feb 22 13:47:40 SuperStor kernel: isp0: LIP Received Feb 22 13:47:40 SuperStor kernel: isp0: s/w notify code 1008 acked ------------------------------------------------------------------------------------------------------------------- My stuff : SCST Server : Fedora Core 6 with kernel 2.6.22.9-61 QLogic Corp. QLE 2462 Fibre Channel Adapter Windows Server: Windows 2003 Enterprise Edition with SP1 Qlogic QLA 2460 Fibre Channel Adapter the qla_isp driver supports Windows initiators ? cheers, Daniel Fernandes _________________________________________________________________ Conheça o Windows Live Spaces, a rede de relacionamentos do Messenger! http://www.amigosdomessenger.com.br/ |
From: Dan P. <dan...@gm...> - 2008-02-21 17:21:58
|
well , I am sorry, but i have not managed to do it with fileio_tgt , but I have added the logs which occur when this problem pops. As we can see , thread 5937 enters the dev_user_get_next_cmd at 18:49:54. it exits on 18:50:20. Might it point on a problem ? what might be the cause ? I think i might be losing scsi commands between those times , Is that logical ? Feb 20 18:49:54 danp kernel: [5937]: ENTRY dev_user_get_next_cmd Feb 20 18:49:54 danp kernel: [0]: ENTRY scst_tgt_cmd_done Feb 20 18:49:54 danp kernel: [0]: ENTRY scst_proccess_redirect_cmd Feb 20 18:49:54 danp kernel: [0]: scst_proccess_redirect_cmd:885:Context: 2 Feb 20 18:49:54 danp kernel: [0]: ENTRY scst_check_retries Feb 20 18:49:54 danp kernel: [0]: EXIT scst_check_retries Feb 20 18:49:54 danp kernel: [0]: scst_schedule_tasklet:44:Adding cmd d359accc to tasklet 1 cmd list Feb 20 18:49:54 danp kernel: [0]: EXIT scst_proccess_redirect_cmd Feb 20 18:49:54 danp kernel: [0]: EXIT scst_tgt_cmd_done Feb 20 18:49:54 danp kernel: [0]: ENTRY scst_cmd_tasklet Feb 20 18:49:55 danp kernel: [0]: ENTRY scst_do_job_active Feb 20 18:49:55 danp kernel: [0]: scst_do_job_active:3045:Deleting cmd d359accc from active cmd list Feb 20 18:49:55 danp kernel: [0]: ENTRY scst_process_active_cmd Feb 20 18:49:55 danp kernel: [0]: ENTRY scst_finish_cmd Feb 20 18:49:55 danp kernel: [0]: ENTRY scst_free_cmd Feb 20 18:49:55 danp kernel: [0]: scst_free_cmd:1262:Freeing cmd d359accc (tag 1127684) Feb 20 18:49:55 danp kernel: [0]: scst_free_cmd:1303:Calling target's on_free_cmd(d359accc) Feb 20 18:49:55 danp kernel: [0]: scst_free_cmd:1305:Target's on_free_cmd() returned Feb 20 18:49:55 danp kernel: [0]: scst_free_cmd:1312:Calling dev handler dh-LUN0 on_free_cmd(d359accc) Feb 20 18:49:55 danp kernel: [0]: ENTRY dev_user_on_free_cmd Feb 20 18:49:55 danp kernel: [0]: dev_user_on_free_cmd:847:ucmd d73357b0, cmd d359accc, buff_cached 1, ubuff 807c000 Feb 20 18:49:55 danp kernel: [0]: sgv_pool_free:694:Freeing sgv_obj d6d2b4f8, order 0, sg_entries d6d2b52c, sg_count 1, allocator_priv e9471ba0 Feb 20 18:49:55 danp kernel: [0]: ucmd_put:228:ucmd d73357b0, ucmd_ref 1 Feb 20 18:49:55 danp kernel: [0]: ENTRY dev_user_free_ucmd Feb 20 18:49:55 danp kernel: [0]: dev_user_free_ucmd:316:Freeing ucmd d73357b0 Feb 20 18:49:55 danp kernel: [0]: cmnd_remove_hash:308:Removed ucmd d73357b0, h=84 Feb 20 18:49:55 danp kernel: [0]: EXIT dev_user_free_ucmd Feb 20 18:49:55 danp kernel: [0]: EXIT dev_user_on_free_cmd Feb 20 18:49:55 danp kernel: [0]: scst_free_cmd:1315:Dev handler dh-LUN0 on_free_cmd() returned Feb 20 18:49:55 danp kernel: [0]: ENTRY scst_release_space Feb 20 18:49:55 danp kernel: [0]: EXIT scst_release_space Feb 20 18:49:55 danp kernel: [0]: __scst_put:466:Decrementing scst_cmd_count(0) Feb 20 18:49:55 danp kernel: [0]: EXIT scst_free_cmd Feb 20 18:49:55 danp kernel: [0]: EXIT scst_finish_cmd: 0x1 Feb 20 18:49:55 danp kernel: [0]: EXIT scst_process_active_cmd Feb 20 18:49:55 danp kernel: [0]: EXIT scst_do_job_active Feb 20 18:49:55 danp kernel: [0]: EXIT scst_cmd_tasklet Feb 20 18:49:55 danp kernel: [4655]: ENTRY scst_rx_cmd Feb 20 18:49:55 danp kernel: [4655]: ENTRY scst_alloc_cmd Feb 20 18:49:55 danp kernel: [4655]: EXIT scst_alloc_cmd Feb 20 18:49:55 danp kernel: [4655]: ENTRY scst_unpack_lun Feb 20 18:49:55 danp kernel: [4655]: scst_unpack_lun:1761:Raw LUN: Feb 20 18:49:55 danp kernel: (h)___0__1__2__3__4__5__6__7__8__9__A__B__C__D__E__F Feb 20 18:49:55 danp kernel: 0: 00 01 00 00 00 00 00 00 ........ Feb 20 18:49:55 danp kernel: [4655]: EXIT scst_unpack_lun: 1 Feb 20 18:49:55 danp kernel: [4655]: scst_rx_cmd:90:cmd d359accc, sess d5a53e80 Feb 20 18:49:55 danp kernel: [4655]: EXIT scst_rx_cmd Feb 20 18:49:55 danp kernel: [4655]: ENTRY scst_cmd_init_done Feb 20 18:49:55 danp kernel: [4655]: scst_cmd_init_done:172:Preferred context: 2 (cmd d359accc) Feb 20 18:49:55 danp kernel: [4655]: scst: scst_cmd_init_done:174:tag=1127720, lun=1, CDB len=16 Feb 20 18:49:55 danp kernel: [4655]: scst_cmd_init_done:176:Recieving CDB: Feb 20 18:49:55 danp kernel: (h)___0__1__2__3__4__5__6__7__8__9__A__B__C__D__E__F Feb 20 18:49:55 danp kernel: 0: 28 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 (............... Feb 20 18:49:55 danp kernel: [4655]: ENTRY scst_init_cmd Feb 20 18:49:55 danp kernel: [4655]: ENTRY __scst_init_cmd Feb 20 18:49:55 danp kernel: [4655]: ENTRY scst_translate_lun Feb 20 18:49:55 danp kernel: [4655]: __scst_get:451:Incrementing scst_cmd_count(1) Feb 20 18:49:55 danp kernel: [4655]: scst_translate_lun:2695:Finding tgt_dev for cmd d359accc (lun 1) Feb 20 18:49:55 danp kernel: [4655]: scst_translate_lun:2700:tgt_dev f0511a4c found Feb 20 18:49:55 danp kernel: [4655]: EXIT scst_translate_lun: 0 Feb 20 18:49:55 danp kernel: [4655]: scst: scst_cmd_set_sn:2625:ORDERED cmd d359accc (op 28) Feb 20 18:49:55 danp kernel: [4655]: scst: scst_cmd_set_sn:2668:cmd(d359accc)->sn: 83 (tgt_dev f0511a4c, *cur_sn_slot 0, num_free_sn_slots 10, prev_cmd_ordered 1, cur_sn_slot 0) Feb 20 18:49:55 danp kernel: [4655]: EXIT __scst_init_cmd: 0 Feb 20 18:49:55 danp kernel: [4655]: EXIT scst_init_cmd: 3 Feb 20 18:49:55 danp kernel: [4655]: scst_cmd_init_done:266:Adding cmd d359accc to active cmd list Feb 20 18:49:55 danp kernel: [4655]: EXIT scst_cmd_init_done Feb 20 18:49:55 danp kernel: [5938]: ENTRY dev_user_poll Feb 20 18:49:55 danp kernel: [5938]: EXIT dev_user_poll: 0x41 Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_ioctl Feb 20 18:49:55 danp kernel: [5945]: dev_user_ioctl:1729:REPLY_AND_GET_CMD Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_reply_get_cmd Feb 20 18:49:55 danp kernel: [5945]: dev_user_reply_get_cmd:1674:ureply 0 Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_get_next_cmd Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_process_scst_commands Feb 20 18:49:55 danp kernel: [5945]: dev_user_process_scst_commands:1461:Deleting cmd d359accc from active cmd list Feb 20 18:49:55 danp kernel: [5945]: ENTRY scst_process_active_cmd Feb 20 18:49:55 danp kernel: [5945]: ENTRY scst_pre_parse Feb 20 18:49:55 danp kernel: [5945]: ENTRY scst_get_cdb_info Feb 20 18:49:55 danp kernel: [5945]: scst_get_cdb_info:1691:opcode=28, cdblen=10 bytes, tblsize=184, dev_type=0 Feb 20 18:49:55 danp kernel: [5945]: scst_get_cdb_info:1708:op = 0x28+'M MMMM '+<READ(10)> Feb 20 18:49:55 danp kernel: [5945]: scst_get_cdb_info:1712:direction=2 flags=1 off=7 Feb 20 18:49:55 danp kernel: [5945]: EXIT scst_get_cdb_info Feb 20 18:49:55 danp kernel: [5945]: scst: scst_pre_parse:345:op_name <READ(10)>, direction=2 (expected 2, set yes), transfer_len=2 (expected len 1024), flags=1 Feb 20 18:49:55 danp kernel: [5945]: EXIT scst_pre_parse: 0 Feb 20 18:49:55 danp kernel: [5945]: ENTRY scst_parse_cmd Feb 20 18:49:55 danp kernel: [5945]: scst_parse_cmd:412:Calling dev handler dh-LUN1 parse(d359accc) Feb 20 18:49:55 danp kernel: [5945]: scst_parse_cmd:413:Parsing: : Feb 20 18:49:55 danp kernel: (h)___0__1__2__3__4__5__6__7__8__9__A__B__C__D__E__F Feb 20 18:49:55 danp kernel: 0: 28 00 00 00 00 00 00 00 02 00 (......... Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_parse Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_alloc_ucmd Feb 20 18:49:55 danp kernel: [5945]: cmnd_insert_hash:297:Inserted ucmd d7335858, h=83 Feb 20 18:49:55 danp kernel: [5945]: dev_user_alloc_ucmd:634:ucmd d7335858 allocated Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_alloc_ucmd: 0xd7335858 Feb 20 18:49:55 danp kernel: [5945]: dev_user_parse:680:ucmd d7335858, cmd d359accc, state 0 Feb 20 18:49:55 danp kernel: [5945]: dev_user_parse:687:PARSE STANDARD: ucmd d7335858 Feb 20 18:49:55 danp kernel: [5945]: ENTRY scst_sbc_generic_parse Feb 20 18:49:55 danp kernel: [5945]: scst_sbc_generic_parse:1880:op_name <READ(10)> direct 2 flags 1 transfer_len 2 Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_get_block: 9 Feb 20 18:49:55 danp kernel: [5945]: scst_sbc_generic_parse:1915:res 0, bufflen 1024, data_len -1, direct 2 Feb 20 18:49:55 danp kernel: [5945]: EXIT scst_sbc_generic_parse: 0 Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_alloc_space Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_alloc_sg Feb 20 18:49:55 danp kernel: [5945]: ENTRY sgv_pool_alloc Feb 20 18:49:55 danp kernel: [5945]: sgv_pool_alloc:508:size=1024, pages=1, order=0, flags=6, *sgv 00000000 Feb 20 18:49:55 danp kernel: [5945]: sgv_pool_alloc:529:Cached sgv_obj ec7e34f8 Feb 20 18:49:55 danp kernel: [5945]: sgv_pool_alloc:639:sgv_obj=ec7e34f8, sg_entries ec7e352c (size=1024, pages=1, sg_count=1, count=1, last_len=1024) Feb 20 18:49:55 danp kernel: [5945]: EXIT sgv_pool_alloc: 0xec7e352c Feb 20 18:49:55 danp kernel: [5945]: dev_user_alloc_sg:497:Buf ucmd e9471a50 Feb 20 18:49:55 danp kernel: [5945]: dev_user_alloc_sg:504:Buf alloced (ucmd d7335858, cached_buff 1, ubuff 807e000, last_len 0, l 1024) Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_alloc_sg: 0 Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_alloc_space: 500 Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_parse: 500 Feb 20 18:49:55 danp kernel: [5945]: scst_parse_cmd:417:Dev handler dh-LUN1 parse() returned 500 Feb 20 18:49:55 danp kernel: [5945]: EXIT scst_parse_cmd: 0x0 Feb 20 18:49:55 danp kernel: [5945]: ENTRY scst_prepare_space Feb 20 18:49:55 danp kernel: [5945]: scst_prepare_space:607:data_buf_alloced set, returning Feb 20 18:49:55 danp kernel: [5945]: EXIT scst_prepare_space: 0x0 Feb 20 18:49:55 danp kernel: [5945]: ENTRY scst_tgt_pre_exec Feb 20 18:49:55 danp kernel: [5945]: EXIT scst_tgt_pre_exec: 0 Feb 20 18:49:55 danp kernel: [5945]: ENTRY scst_send_to_midlev Feb 20 18:49:55 danp kernel: [5945]: __scst_get:451:Incrementing scst_cmd_count(2) Feb 20 18:49:55 danp kernel: [5945]: ENTRY scst_inc_on_dev_cmd Feb 20 18:49:55 danp kernel: [5945]: scst_inc_on_dev_cmd:2764:New on_dev_count 1 Feb 20 18:49:55 danp kernel: [5945]: EXIT scst_inc_on_dev_cmd: 0 Feb 20 18:49:55 danp kernel: [5945]: ENTRY scst_do_send_to_midlev Feb 20 18:49:55 danp kernel: [5945]: ENTRY scst_pre_exec Feb 20 18:49:55 danp kernel: [5945]: EXIT scst_pre_exec: 1 Feb 20 18:49:55 danp kernel: [5945]: ENTRY scst_local_exec Feb 20 18:49:55 danp kernel: [5945]: EXIT scst_local_exec: 1 Feb 20 18:49:55 danp kernel: [5945]: scst_do_send_to_midlev:1666:Calling dev handler dh-LUN1 exec(d359accc) Feb 20 18:49:55 danp kernel: [5945]: scst_do_send_to_midlev:1667:Execing: : Feb 20 18:49:55 danp kernel: (h)___0__1__2__3__4__5__6__7__8__9__A__B__C__D__E__F Feb 20 18:49:55 danp kernel: 0: 28 00 00 00 00 00 00 00 02 00 (......... Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_exec Feb 20 18:49:55 danp kernel: [5945]: dev_user_exec:791:Preparing EXEC for user space (ucmd=d7335858, h=83, bufflen 1024, data_len 1024, ubuff 807e000) Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_add_to_ready Feb 20 18:49:55 danp kernel: [5945]: dev_user_add_to_ready:996:Adding ucmd d7335858 to ready cmd list Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_add_to_ready Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_exec Feb 20 18:49:55 danp kernel: [5945]: scst_do_send_to_midlev:1672:Dev handler dh-LUN1 exec() returned 0 Feb 20 18:49:55 danp kernel: [5945]: EXIT scst_do_send_to_midlev Feb 20 18:49:55 danp kernel: [5945]: __scst_put:466:Decrementing scst_cmd_count(1) Feb 20 18:49:55 danp kernel: [5945]: EXIT scst_send_to_midlev: 0x1 Feb 20 18:49:55 danp kernel: [5945]: EXIT scst_process_active_cmd Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_process_scst_commands: 1 Feb 20 18:49:55 danp kernel: [5945]: __dev_user_get_next_cmd:1482:Found ready ucmd d73353c0 Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_get_next_cmd: 0 Feb 20 18:49:55 danp kernel: [5945]: dev_user_reply_get_cmd:1704:UCMD: Feb 20 18:49:55 danp kernel: (h)___0__1__2__3__4__5__6__7__8__9__A__B__C__D__E__F Feb 20 18:49:55 danp kernel: 0: 00 00 00 00 00 00 00 00 32 00 00 00 06 73 08 80 ........2....s.. Feb 20 18:49:55 danp kernel: 10: 00 f0 0a 08 00 00 00 00 28 00 00 00 98 50 00 00 ........(....P.. Feb 20 18:49:55 danp kernel: 20: 10 00 00 00 00 00 00 00 0a 00 00 00 00 20 00 00 ............. .. Feb 20 18:49:55 danp kernel: 30: 00 20 00 00 00 20 00 00 00 00 00 00 00 00 00 00 . ... .......... Feb 20 18:49:55 danp kernel: 40: 02 02 00 00 4c 1d 00 00 00 00 00 00 00 00 00 00 ....L........... Feb 20 18:49:55 danp kernel: 50: 00 00 00 00 00 00 00 00 ........ Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_reply_get_cmd: 0 Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_ioctl: 0 Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_ioctl Feb 20 18:49:55 danp kernel: [5945]: dev_user_ioctl:1734:REPLY_CMD Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_reply_cmd Feb 20 18:49:55 danp kernel: [5945]: dev_user_reply_cmd:1434:Reply: Feb 20 18:49:55 danp kernel: (h)___0__1__2__3__4__5__6__7__8__9__A__B__C__D__E__F Feb 20 18:49:55 danp kernel: 0: 32 00 00 00 06 73 08 80 00 00 00 00 00 00 00 00 2....s.......... Feb 20 18:49:55 danp kernel: 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Feb 20 18:49:55 danp kernel: 20: 00 00 00 00 00 00 00 00 ........ Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_process_reply Feb 20 18:49:55 danp kernel: [5945]: __ucmd_find_hash:274:Found ucmd d73353c0 Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_process_reply_on_cache_free Feb 20 18:49:55 danp kernel: [5945]: dev_user_process_reply_on_cache_free:1188:ON CACHE FREE ucmd d73353c0 Feb 20 18:49:55 danp kernel: [5945]: ucmd_put:228:ucmd d73353c0, ucmd_ref 1 Feb 20 18:49:55 danp kernel: [5945]: ENTRY dev_user_free_ucmd Feb 20 18:49:55 danp kernel: [5945]: dev_user_free_ucmd:316:Freeing ucmd d73353c0 Feb 20 18:49:55 danp kernel: [5945]: cmnd_remove_hash:308:Removed ucmd d73353c0, h=50 Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_free_ucmd Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_process_reply_on_cache_free: 0 Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_process_reply: 0 Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_reply_cmd: 0 Feb 20 18:49:55 danp kernel: [5945]: EXIT dev_user_ioctl: 0 Feb 20 18:50:05 danp kernel: [7]: ENTRY sgv_pool_cached_pitbool Feb 20 18:50:05 danp kernel: [7]: EXIT sgv_pool_cached_pitbool Feb 20 18:50:20 danp kernel: [7]: ENTRY sgv_pool_cached_pitbool Feb 20 18:50:20 danp kernel: [7]: dev_user_free_sg_entries:431:Freeing data pages (sg=d6d2b52c, sg_count=1, priv e9471ba0) Feb 20 18:50:20 danp kernel: [7]: ENTRY __dev_user_free_sg_entries Feb 20 18:50:20 danp kernel: [7]: __dev_user_free_sg_entries:412:Freeing data pages (ucmd=e9471ba0, ubuff=807c000, buff_cached=1) Feb 20 18:50:20 danp kernel: [7]: ENTRY dev_user_unmap_buf Feb 20 18:50:20 danp kernel: [7]: dev_user_unmap_buf:388:Unmapping data pages (ucmd e9471ba0, ubuff 807c000, num 1) Feb 20 18:50:20 danp kernel: [7]: EXIT dev_user_unmap_buf Feb 20 18:50:20 danp kernel: [7]: ENTRY dev_user_on_cached_mem_free Feb 20 18:50:20 danp kernel: [7]: dev_user_on_cached_mem_free:367:Preparing ON_CACHED_MEM_FREE (ucmd e9471ba0, h 1, ubuff 807c000) Feb 20 18:50:20 danp kernel: [7]: ENTRY dev_user_add_to_ready Feb 20 18:50:20 danp kernel: [7]: dev_user_add_to_ready:996:Adding ucmd e9471ba0 to ready cmd list Feb 20 18:50:20 danp kernel: [7]: dev_user_add_to_ready:1001:Waking up dev f74ff800 Feb 20 18:50:20 danp kernel: [7]: EXIT dev_user_add_to_ready Feb 20 18:50:20 danp kernel: [7]: EXIT dev_user_on_cached_mem_free Feb 20 18:50:20 danp kernel: [7]: EXIT __dev_user_free_sg_entries Feb 20 18:50:20 danp kernel: [7]: EXIT sgv_pool_cached_pitbool Feb 20 18:50:20 danp kernel: [5937]: ENTRY dev_user_process_scst_commands Feb 20 18:50:20 danp kernel: [5937]: EXIT dev_user_process_scst_commands: 0 Feb 20 18:50:20 danp kernel: [5937]: __dev_user_get_next_cmd:1482:Found ready ucmd e9471ba0 Feb 20 18:50:20 danp kernel: [5937]: EXIT dev_user_get_next_cmd: 0 On Tue, Feb 19, 2008 at 11:04 AM, Vladislav Bolkhovitin <vs...@vl...> wrote: > Dan Porat wrote: > > My Question regards a user space handler. > > > > We are facing a situation in which we listen using a poll to a file > > descriptor. > > 1.Listening to FD =1 using epoll. > > 2.FD =1 is asserted (There is Data on that FD). > > 3.An SCST_USER_REPLY_CMD is issued by the application , answering a > > former request on FD=1. > > 4.SCST_USER_REPLY_AND_GET is issued by a different thread on FD=1. > > 5.The system goes into very unstable state. > > What is "very unstable state"? Any logs/messages? > > Can you reproduce it with the corresponding fileio_tgt modifications? > > > Why and how to prevent ? > > Anyone has ideas ? > > > > Thanks > > > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Scst-devel mailing list > > Scs...@li... > > https://lists.sourceforge.net/lists/listinfo/scst-devel > > |
From: Bart V. A. <bar...@gm...> - 2008-02-20 08:41:27
|
On Feb 20, 2008 8:34 AM, Erez Zilber <er...@vo...> wrote: > Bart Van Assche wrote: > > Or: data sent during the first burst is not transferred via one-sided > > remote memory reads or writes but via two-sided send/receive > > operations. At least on my setup, these operations are as fast as > > one-sided remote memory reads or writes. As an example, I obtained the > > following numbers on my setup (SDR 4x network); > > ib_write_bw: 933 MB/s. > > ib_read_bw: 905 MB/s. > > ib_send_bw: 931 MB/s. > > According to these numbers one can think that you don't need RDMA at > all, just send iSCSI PDUs over IB. Sorry, but you are misinterpreting what I wrote. > The benchmarks that you use are > synthetic IB benchmarks that are not equivalent to iSCSI over iSER. They > just send IB packets. I'm not surprised that you got more or less the > same performance because, AFAIK, ib_send_bw doesn't copy data (unlike > iSCSI that has to copy data that is sent/received without RDMA). I agree that ib_write_bw / ib_read_bw / ib_send_bw performance results are not equivalent to iSCSI over iSER. The reason that I included these performance results was to illustrate that two-sided data transfers over IB are about as fast as one-sided data transfers. > When you use RDMA with iSCSI (i.e. iSER), you don't need to create iSCSI > PDUs and process them. The CPU is not busy as it is with iSCSI over TCP > because no data copies are required. Another advantage is that you don't > need header/data digest because the IB HW does that. As far as I know, when using iSER, the FirstBurstLength bytes of data are sent via two-sided data transfers, and there is no CPU intervention required to transfer the data itself over the IB network. Bart Van Assche. |
From: Erez Z. <erezz@Voltaire.COM> - 2008-02-20 07:34:37
|
Bart Van Assche wrote: > On Feb 18, 2008 10:43 AM, Erez Zilber <er...@vo...> wrote: > >> If you use a high value for FirstBurstLength, all (or most) of your data >> will be sent as unsolicited data-out PDUs. These PDUs don't use the RDMA >> engine, so you miss the advantage of IB. >> > > Hello Erez, > > Did you notice the e-mail Roland Dreier wrote on Februari 6, 2008 ? > This is what Roland wrote: > >> I think the confusion here is caused by a slight misuse of the term >> "RDMA". It is true that all data is always transported over an >> InfiniBand connection when iSER is used, but not all such transfers >> are one-sided RDMA operations; some data can be transferred using >> send/receive operations. >> > > Yes, I saw that. I tried to give an explanation with more details. > Or: data sent during the first burst is not transferred via one-sided > remote memory reads or writes but via two-sided send/receive > operations. At least on my setup, these operations are as fast as > one-sided remote memory reads or writes. As an example, I obtained the > following numbers on my setup (SDR 4x network); > ib_write_bw: 933 MB/s. > ib_read_bw: 905 MB/s. > ib_send_bw: 931 MB/s. > > According to these numbers one can think that you don't need RDMA at all, just send iSCSI PDUs over IB. The benchmarks that you use are synthetic IB benchmarks that are not equivalent to iSCSI over iSER. They just send IB packets. I'm not surprised that you got more or less the same performance because, AFAIK, ib_send_bw doesn't copy data (unlike iSCSI that has to copy data that is sent/received without RDMA). When you use RDMA with iSCSI (i.e. iSER), you don't need to create iSCSI PDUs and process them. The CPU is not busy as it is with iSCSI over TCP because no data copies are required. Another advantage is that you don't need header/data digest because the IB HW does that. Erez |
From: Daniel F. <dfe...@ho...> - 2008-02-19 12:37:12
|
---------------------------------------- > Date: Tue, 19 Feb 2008 13:14:45 +0100 > From: sta...@op... > To: sta...@op... > CC: dfe...@ho...; scs...@li... > Subject: Re: [Scst-devel] qla_isp Driver kernel oops > > Stanislaw wrote: >> Daniel Fernandes wrote: >>> Hi there, i start testing the scst rev 285 with qla_isp driver, with vdisk >>> driver with best parameters and gives this kernel oops after i do >> qla_isp will be broken for a while, please don't use > Driver should work now. Tests and bug reports welcome. > Format of file qla_isp/X change to "channel:enable", > so to turn on use > echo "0:1"> /proc/scsi_tgt/qla_isp/X Thanks Gruszka, i will test driver and let you know if it is all ok! Daniel Fernandes > > Stanislaw Gruszka _________________________________________________________________ Cansado de espaço para só 50 fotos? Conheça o Spaces, o site de relacionamentos com até 6,000 fotos! http://www.amigosdomessenger.com.br |
From: Vladislav B. <vs...@vl...> - 2008-02-19 12:08:35
|
Joe Landman wrote: > Hi folks: > > I want to set up an SCST target for each of two different > LUN/partitions on disks using vdisk, and have one LUN exposed only on > one interface (two interfaces). > > Here is how I thought I should do it at first (naive test), but this > doesn't work, as the initiator attaches to both LUNs. > > echo "open vdisk0 /dev/sdb1 512 BLOCKIO" > /proc/scsi_tgt/vdisk/vdisk > echo "open vdisk1 /dev/sdc1 512 BLOCKIO " > /proc/scsi_tgt/vdisk/vdisk > echo "add vdisk0 0" >/proc/scsi_tgt/groups/Default/devices > echo "add vdisk1 1" >/proc/scsi_tgt/groups/Default/devices > > Looking over the document offers some hints of what we need to do. It > looks like the steps are something like this: > > 1) add a second target in /etc/iscsi-scst.conf > > 2) associate groups with each target > > 3) associate vdisks with groups (we are doing this with the default > device above) > > 4) add/open specific devices with specific vdisks. > > Ok. #1 isn't hard, though I am not sure what we should configure apart > from declaring another target. The usual Lun ... line (as in IET) > doesn't work here, so we can't use this to bind Luns to targets. This > is done using the echo bits above. > > #2 is something I am not sure about. It appears that the group name > needs to be encoded in the target. > > #3 I tried, but must be misunderstanding something pretty fundamental. > > #4 should be easy (very similar to the echo statments, but redirecting > to the specific groups devices). > > Has anyone done something like this? Is it possible? Limiting visibility of devices per interface basis isn't implemented (and I'm not sure if it should be implemented). Instead you can create two targets and limit access to them based on IP net using initiators.allow/initiators.deny files (simpler). Or (harder) you can create for each initiator its personal security group with device, which it should see connecting to a single target. > Thanks. > > Joe > |
From: Stanislaw <sta...@op...> - 2008-02-19 12:03:12
|
Stanislaw wrote: > Daniel Fernandes wrote: >> Hi there, i start testing the scst rev 285 with qla_isp driver, with vdisk >> driver with best parameters and gives this kernel oops after i do > qla_isp will be broken for a while, please don't use Driver should work now. Tests and bug reports welcome. Format of file qla_isp/X change to "channel:enable", so to turn on use echo "0:1" > /proc/scsi_tgt/qla_isp/X Stanislaw Gruszka |
From: Vladislav B. <vs...@vl...> - 2008-02-19 10:52:06
|
Dan Porat wrote: > My Question regards a user space handler. > > We are facing a situation in which we listen using a poll to a file > descriptor. > 1.Listening to FD =1 using epoll. > 2.FD =1 is asserted (There is Data on that FD). > 3.An SCST_USER_REPLY_CMD is issued by the application , answering a > former request on FD=1. > 4.SCST_USER_REPLY_AND_GET is issued by a different thread on FD=1. > 5.The system goes into very unstable state. What is "very unstable state"? Any logs/messages? Can you reproduce it with the corresponding fileio_tgt modifications? > Why and how to prevent ? > Anyone has ideas ? > > Thanks > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Scst-devel mailing list > Scs...@li... > https://lists.sourceforge.net/lists/listinfo/scst-devel |
From: Dan P. <dan...@gm...> - 2008-02-18 14:44:36
|
My Question regards a user space handler. We are facing a situation in which we listen using a poll to a file descriptor. 1.Listening to FD =1 using epoll. 2.FD =1 is asserted (There is Data on that FD). 3.An SCST_USER_REPLY_CMD is issued by the application , answering a former request on FD=1. 4.SCST_USER_REPLY_AND_GET is issued by a different thread on FD=1. 5.The system goes into very unstable state. Why and how to prevent ? Anyone has ideas ? Thanks |
From: Daniel F. <dfe...@ho...> - 2008-02-18 11:58:05
|
---------------------------------------- > Date: Sun, 17 Feb 2008 22:30:18 -0500 > From: la...@sc... > To: scs...@li... > Subject: [Scst-devel] Quick "howto" question > > Hi folks: > > I want to set up an SCST target for each of two different > LUN/partitions on disks using vdisk, and have one LUN exposed only on > one interface (two interfaces). > > Here is how I thought I should do it at first (naive test), but this > doesn't work, as the initiator attaches to both LUNs. > > echo "open vdisk0 /dev/sdb1 512 BLOCKIO"> /proc/scsi_tgt/vdisk/vdisk > echo "open vdisk1 /dev/sdc1 512 BLOCKIO "> /proc/scsi_tgt/vdisk/vdisk > echo "add vdisk0 0">/proc/scsi_tgt/groups/Default/devices > echo "add vdisk1 1">/proc/scsi_tgt/groups/Default/devices well you are masking the two luns to same group "DEFAULT" you should create other security group (ex: tests) and do the following command: echo "add vdisk1 0">/proc/scsi_tgt/groups/tests/devices Regards Daniel Fernandes > > Looking over the document offers some hints of what we need to do. It > looks like the steps are something like this: > > 1) add a second target in /etc/iscsi-scst.conf > > 2) associate groups with each target > > 3) associate vdisks with groups (we are doing this with the default > device above) > > 4) add/open specific devices with specific vdisks. > > Ok. #1 isn't hard, though I am not sure what we should configure apart > from declaring another target. The usual Lun ... line (as in IET) > doesn't work here, so we can't use this to bind Luns to targets. This > is done using the echo bits above. > > #2 is something I am not sure about. It appears that the group name > needs to be encoded in the target. > > #3 I tried, but must be misunderstanding something pretty fundamental. > > #4 should be easy (very similar to the echo statments, but redirecting > to the specific groups devices). > > Has anyone done something like this? Is it possible? > > Thanks. > > Joe > > -- > Joseph Landman, Ph.D > Founder and CEO > Scalable Informatics LLC, > email: la...@sc... > web : http://www.scalableinformatics.com > http://jackrabbit.scalableinformatics.com > phone: +1 734 786 8423 > fax : +1 866 888 3112 > cell : +1 734 612 4615 > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Scst-devel mailing list > Scs...@li... > https://lists.sourceforge.net/lists/listinfo/scst-devel _________________________________________________________________ Confira vídeos com notícias do NY Times, gols direto do Lance, videocassetadas e muito mais no MSN Video! http://video.msn.com/?mkt=pt-br |
From: Bart V. A. <bar...@gm...> - 2008-02-18 11:01:30
|
On Feb 18, 2008 10:43 AM, Erez Zilber <er...@vo...> wrote: > If you use a high value for FirstBurstLength, all (or most) of your data > will be sent as unsolicited data-out PDUs. These PDUs don't use the RDMA > engine, so you miss the advantage of IB. Hello Erez, Did you notice the e-mail Roland Dreier wrote on Februari 6, 2008 ? This is what Roland wrote: > I think the confusion here is caused by a slight misuse of the term > "RDMA". It is true that all data is always transported over an > InfiniBand connection when iSER is used, but not all such transfers > are one-sided RDMA operations; some data can be transferred using > send/receive operations. Or: data sent during the first burst is not transferred via one-sided remote memory reads or writes but via two-sided send/receive operations. At least on my setup, these operations are as fast as one-sided remote memory reads or writes. As an example, I obtained the following numbers on my setup (SDR 4x network); ib_write_bw: 933 MB/s. ib_read_bw: 905 MB/s. ib_send_bw: 931 MB/s. Bart Van Assche. |
From: Erez Z. <erezz@Voltaire.COM> - 2008-02-18 09:43:53
|
Bart Van Assche wrote: > On Feb 5, 2008 6:01 PM, Erez Zilber <er...@vo...> wrote: > >> Using such large values for FirstBurstLength will give you poor >> performance numbers for WRITE commands (with iSER). FirstBurstLength >> means how much data should you send as unsolicited data (i.e. without >> RDMA). It means that your WRITE commands were sent without RDMA. >> > > Sorry, but I'm afraid you got this wrong. When the iSER transport is > used instead of TCP, all data is sent via RDMA, including unsolicited > data. If you have look at the iSER implementation in the Linux kernel > (source files under drivers/infiniband/ulp/iser), you will see that > all data is transferred via RDMA and not via TCP/IP. > > When you execute WRITE commands with iSCSI, it works like this: EDTL (Expected data length) - the data length of your command FirstBurstLength - the length of data that will be sent as unsolicited data (i.e. as immediate data with the SCSI command and as unsolicited data-out PDUs) If you use a high value for FirstBurstLength, all (or most) of your data will be sent as unsolicited data-out PDUs. These PDUs don't use the RDMA engine, so you miss the advantage of IB. If you use a lower value for FirstBurstLength, EDTL - FirstBurstLength bytes will be sent as solicited data-out PDUs. With iSER, solicited data-out PDUs are RDMA operations. I hope that I'm more clear now. Erez |
From: Joe L. <la...@sc...> - 2008-02-18 03:30:29
|
Hi folks: I want to set up an SCST target for each of two different LUN/partitions on disks using vdisk, and have one LUN exposed only on one interface (two interfaces). Here is how I thought I should do it at first (naive test), but this doesn't work, as the initiator attaches to both LUNs. echo "open vdisk0 /dev/sdb1 512 BLOCKIO" > /proc/scsi_tgt/vdisk/vdisk echo "open vdisk1 /dev/sdc1 512 BLOCKIO " > /proc/scsi_tgt/vdisk/vdisk echo "add vdisk0 0" >/proc/scsi_tgt/groups/Default/devices echo "add vdisk1 1" >/proc/scsi_tgt/groups/Default/devices Looking over the document offers some hints of what we need to do. It looks like the steps are something like this: 1) add a second target in /etc/iscsi-scst.conf 2) associate groups with each target 3) associate vdisks with groups (we are doing this with the default device above) 4) add/open specific devices with specific vdisks. Ok. #1 isn't hard, though I am not sure what we should configure apart from declaring another target. The usual Lun ... line (as in IET) doesn't work here, so we can't use this to bind Luns to targets. This is done using the echo bits above. #2 is something I am not sure about. It appears that the group name needs to be encoded in the target. #3 I tried, but must be misunderstanding something pretty fundamental. #4 should be easy (very similar to the echo statments, but redirecting to the specific groups devices). Has anyone done something like this? Is it possible? Thanks. Joe -- Joseph Landman, Ph.D Founder and CEO Scalable Informatics LLC, email: la...@sc... web : http://www.scalableinformatics.com http://jackrabbit.scalableinformatics.com phone: +1 734 786 8423 fax : +1 866 888 3112 cell : +1 734 612 4615 |
From: Nezer Z. <nza...@ma...> - 2008-02-17 08:58:16
|
hello all, I would like to know if anybody can clue me on some referance names of companies who use SCST, out of which how many are using SCST in production and how many plan to use it for production? how many use SCST drivers in Enterprise environments? have anybody experienced any crtical issues with SCST in production environment? Thanks in advance Nezer J. Zaidenberg |
From: Bart V. A. <bar...@gm...> - 2008-02-15 15:02:52
|
On Thu, Feb 7, 2008 at 2:45 PM, Vladislav Bolkhovitin <vs...@vl...> wrote: > > Bart Van Assche wrote: > > Since the focus of this thread shifted somewhat in the last few > > messages, I'll try to summarize what has been discussed so far: > > - There was a number of participants who joined this discussion > > spontaneously. This suggests that there is considerable interest in > > networked storage and iSCSI. > > - It has been motivated why iSCSI makes sense as a storage protocol > > (compared to ATA over Ethernet and Fibre Channel over Ethernet). > > - The direct I/O performance results for block transfer sizes below 64 > > KB are a meaningful benchmark for storage target implementations. > > - It has been discussed whether an iSCSI target should be implemented > > in user space or in kernel space. It is clear now that an > > implementation in the kernel can be made faster than a user space > > implementation (http://kerneltrap.org/mailarchive/linux-kernel/2008/2/4/714804). > > Regarding existing implementations, measurements have a.o. shown that > > SCST is faster than STGT (30% with the following setup: iSCSI via > > IPoIB and direct I/O block transfers with a size of 512 bytes). > > - It has been discussed which iSCSI target implementation should be in > > the mainstream Linux kernel. There is no agreement on this subject > > yet. The short-term options are as follows: > > 1) Do not integrate any new iSCSI target implementation in the > > mainstream Linux kernel. > > 2) Add one of the existing in-kernel iSCSI target implementations to > > the kernel, e.g. SCST or PyX/LIO. > > 3) Create a new in-kernel iSCSI target implementation that combines > > the advantages of the existing iSCSI kernel target implementations > > (iETD, STGT, SCST and PyX/LIO). > > > > As an iSCSI user, I prefer option (3). The big question is whether the > > various storage target authors agree with this ? > > I tend to agree with some important notes: > > 1. IET should be excluded from this list, iSCSI-SCST is IET updated for > SCST framework with a lot of bugfixes and improvements. > > 2. I think, everybody will agree that Linux iSCSI target should work > over some standard SCSI target framework. Hence the choice gets > narrower: SCST vs STGT. I don't think there's a way for a dedicated > iSCSI target (i.e. PyX/LIO) in the mainline, because of a lot of code > duplication. Nicholas could decide to move to either existing framework > (although, frankly, I don't think there's a possibility for in-kernel > iSCSI target and user space SCSI target framework) and if he decide to > go with SCST, I'll be glad to offer my help and support and wouldn't > care if LIO-SCST eventually replaced iSCSI-SCST. The better one should win. If I understood the above correctly, regarding a kernel space iSCSI target implementation, only LIO-SE and SCST should be considered. What I know today about these Linux iSCSI target implementations is as follows: * SCST performs slightly better than LIO-SE, and LIO-SE performs slightly better than STGT (both with regard to latency and with regard to bandwidth). * The coding style of SCST is closer to the Linux kernel coding style than the coding style of the LIO-SE project. * The structure of SCST is closer to what Linus expects than the structure of LIO-SE (i.e., authentication handled in userspace, data transfer handled by the kernel -- LIO-SE handles both in kernel space). * Until now I did not encounter any strange behavior in SCST. The issues I encountered with LIO-SE are being resolved via the LIO-SE mailing list (http://groups.google.com/group/linux-iscsi-target-dev). It would take too much effort to develop a new kernel space iSCSI target from scratch -- we should start from either LIO-SE or SCST. My opinion is that the best approach is to start with integrating SCST in the mainstream kernel, and that the more advanced features from LIO-SE that are not yet in SCST can be ported from LIO-SE to the SCST framework. Nicholas, do you think the structure of SCST is powerful enough to be extended with LIO-SE's powerful features like ERL-2 ? Bart Van Assche. |
From: Bart V. A. <bar...@gm...> - 2008-02-15 14:37:31
|
On Thu, Feb 14, 2008 at 10:19 PM, Vu Pham <hu...@ya...> wrote: > > The message indeed disappears if I compile the ib_srpt module inside > > the SCST tree. > > Could you share the Makefile? I want to add it to srpt.git Hello Vu, After having copied ib_srpt.c and ib_srpt.h to the directory scst/src/dev_handlers inside the SCST source tree, the ib_srpt module can be compiled inside the SCST tree with the following patch: Index: scst/src/dev_handlers/Makefile =================================================================== --- scst/src/dev_handlers/Makefile (revision 287) +++ scst/src/dev_handlers/Makefile (working copy) @@ -30,6 +30,7 @@ SCST_INC_DIR := $(SUBDIRS)/../include obj-m := scst_cdrom.o scst_changer.o scst_disk.o scst_modisk.o scst_tape.o \ + ib_srpt.o \ scst_vdisk.o scst_raid.o scst_processor.o scst_user.o obj-$(CONFIG_SCSI_TARGET_DISK) += scst_disk.o @@ -41,6 +42,7 @@ obj-$(CONFIG_SCSI_TARGET_PROCESSOR) += scst_processor.o obj-$(CONFIG_SCSI_TARGET_VDISK) += scst_vdisk.o obj-$(CONFIG_SCSI_TARGET_USER) += scst_user.o +obj-$(CONFIG_SCSI_TARGET_DISK) += ib_srpt.o else ifeq ($(KDIR),) @@ -67,6 +69,7 @@ endif EXTRA_CFLAGS += -I$(SUBDIRS) -I$(SCST_INC_DIR) -Wextra -Wno-unused-parameter +EXTRA_CFLAGS += -Idrivers/infiniband/include EXTRA_CFLAGS += -DEXTRACHECKS Note: this will only work if the InfiniBand drivers have been built inside the kernel tree, and if the ofa-kernel RPM has NOT been installed. Bart Van Assche. |
From: Vladislav B. <vs...@vl...> - 2008-02-15 09:58:11
|
Tomasz Chmielewski wrote: > Sometimes, I need to resize the the target, because all data doesn't fit > anymore. Easy to do on the target machine if you're using LVM. > > However, is it possible to do so so that both target and the initiator > are notified about the change, without restarting the initiator? If not > right now, is it technically possible to do so? Yes, that's technically possible and SCSI even has a standard mechanism for that (CAPACITY DATA CHANGED Unit Attention). But I don't know OS, which honors this UA. So, currently all you can do is to manually trigger a device rescan after you changed the size of the device on the target. On Linux you can do that via /sys/block/X/device/rescan, although it doesn't work pretty reliably for me. > I was thinking about something similar to SCSI soft resetting, which can > be triggered by (here, for my first disk): > > # echo - - - > /sys/class/scsi_host/host0/scan > # dmesg > ata1: soft resetting link > ata1.00: configured for UDMA/133 > ata1: EH complete > sd 0:0:0:0: [sda] 78242976 512-byte hardware sectors (40060 MB) > sd 0:0:0:0: [sda] Write Protect is off > sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't > support DPO or FUA > > > Unfortunately, soft resetting doesn't seem to work for iSCSI disks. And shouldn't. It's completely different action. |
From: Tomasz C. <ma...@wp...> - 2008-02-15 08:54:41
|
Sometimes, I need to resize the the target, because all data doesn't fit anymore. Easy to do on the target machine if you're using LVM. However, is it possible to do so so that both target and the initiator are notified about the change, without restarting the initiator? If not right now, is it technically possible to do so? I was thinking about something similar to SCSI soft resetting, which can be triggered by (here, for my first disk): # echo - - - > /sys/class/scsi_host/host0/scan # dmesg ata1: soft resetting link ata1.00: configured for UDMA/133 ata1: EH complete sd 0:0:0:0: [sda] 78242976 512-byte hardware sectors (40060 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Unfortunately, soft resetting doesn't seem to work for iSCSI disks. -- Tomasz Chmielewski http://wpkg.org |
From: Vladislav B. <vs...@vl...> - 2008-02-15 07:36:23
|
Vu Pham wrote: > Bart Van Assche wrote: > >> On Feb 12, 2008 6:53 PM, Vu Pham <hu...@ya...> wrote: >> >>> Hi Bart, >>> >>> Applied your patch - thanks >>> >>> -vu >> >> >> Hello Vu, >> >> Can you please test SRPT with CONFIG_DEBUG_SG enabled ? An >> sg_init_table() call is still missing. >> >> Bart. >> > > Could you try this patch? As I already pointed out, if you don't want double memset(), that isn't sufficient. The corresponding kzalloc() should be changed on kmalloc() as well. > -vu > > > ------------------------------------------------------------------------ > > diff --git a/ib_srpt.c b/ib_srpt.c > index 87f0b58..6094981 100644 > --- a/ib_srpt.c > +++ b/ib_srpt.c > @@ -2187,6 +2187,10 @@ static int srpt_alloc_data_buf(struct scst_cmd *scmnd) > scmnd->sg = scat; > db = ioctx->rbufs; > > +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,23) > + sg_init_table(scat, nrdma); > +#endif > + > for (i = 0, index = 0; i < nrdma && tsize > 0; ++i) { > mel = srpt_get_mem_elem(&index); > if (!mel || !index) |
From: Vu P. <hu...@ya...> - 2008-02-14 21:21:46
|
Bart Van Assche wrote: > On Feb 12, 2008 6:53 PM, Vu Pham <hu...@ya...> wrote: >> Hi Bart, >> >> Applied your patch - thanks >> >> -vu > > Hello Vu, > > Can you please test SRPT with CONFIG_DEBUG_SG enabled ? An > sg_init_table() call is still missing. > > Bart. > Could you try this patch? -vu |
From: Vu P. <hu...@ya...> - 2008-02-14 21:20:40
|
Bart, > On Tue, Feb 12, 2008 at 7:02 PM, Vu Pham <hu...@ya...> wrote: >> SRPT call scst_unregister() same way as iscsi >> Does it happen because we build SRPT out-of-scst tree? >> >> Bart, could you drop srpt.git into scst source tree, create >> a makefile for it (same as iscsi), build and load to see if >> the problem is still there or not? > > The message indeed disappears if I compile the ib_srpt module inside > the SCST tree. Could you share the Makefile? I want to add it to srpt.git > > By the way, can you please strip the carriage returns from > srpt_inc/scst_r245.patch (git://git.openfabrics.org/~vu/srpt_inc) ? > These probably slept in accidentally. > Corrected. thanks, -vu |
From: Dan P. <dan...@gm...> - 2008-02-14 16:50:55
|
Hi There! WE have an scst driver which works , but sometimes gets stuck. The hardware we work with is QLE2462. 1.I would like to know if there is any virtualization environment in which this hardware is totally recognized. 2.What is the preferred way to debug these kind of software codes (scst_user). How do I debug once the module is stuck ? Is there a way to release it ? Thanks. Dan Porat |
From: Bart V. A. <bar...@gm...> - 2008-02-14 15:59:13
|
On Tue, Feb 12, 2008 at 7:02 PM, Vu Pham <hu...@ya...> wrote: > > SRPT call scst_unregister() same way as iscsi > Does it happen because we build SRPT out-of-scst tree? > > Bart, could you drop srpt.git into scst source tree, create > a makefile for it (same as iscsi), build and load to see if > the problem is still there or not? The message indeed disappears if I compile the ib_srpt module inside the SCST tree. By the way, can you please strip the carriage returns from srpt_inc/scst_r245.patch (git://git.openfabrics.org/~vu/srpt_inc) ? These probably slept in accidentally. Bart Van Assche. |