Re: [PATCH] iscsi: Perform connection failure entirely in kernel space
On 12/10/2019 06:05 PM, Mike Christie wrote:
> On 12/09/2019 12:20 PM, Gabriel Krisman Bertazi wrote:
>> From: Bharath Ravi
>>
>> Connection failure processing depends on a daemon being present to (at
>> least) stop the connection and start recovery. This is a problem on a
>> multipath scenario, where if the daemon failed for whatever reason, the
>> SCSI path is never marked as down, multipath won't perform the
>> failover and IO to the device will be forever waiting for that
>> connection to come back.
>>
>> This patch implements an optional feature in the iscsi module, to
>> perform the connection failure inside the kernel. This way, the
>> failover can happen and pending IO can continue even if the daemon is
>> dead. Once the daemon comes alive again, it can perform recovery
>> procedures if applicable.
>>
>> Co-developed-by: Dave Clausen
>> Signed-off-by: Dave Clausen
>> Co-developed-by: Nick Black
>> Signed-off-by: Nick Black
>> Co-developed-by: Vaibhav Nagarnaik
>> Signed-off-by: Vaibhav Nagarnaik
>> Co-developed-by: Anatol Pomazau
>> Signed-off-by: Anatol Pomazau
>> Co-developed-by: Tahsin Erdogan
>> Signed-off-by: Tahsin Erdogan
>> Co-developed-by: Frank Mayhar
>> Signed-off-by: Frank Mayhar
>> Co-developed-by: Junho Ryu
>> Signed-off-by: Junho Ryu
>> Co-developed-by: Khazhismel Kumykov
>> Signed-off-by: Khazhismel Kumykov
>> Signed-off-by: Bharath Ravi
>> Co-developed-by: Gabriel Krisman Bertazi
>> Signed-off-by: Gabriel Krisman Bertazi
>> ---
>> drivers/scsi/scsi_transport_iscsi.c | 46 +
>> include/scsi/scsi_transport_iscsi.h | 1 +
>> 2 files changed, 47 insertions(+)
>>
>> diff --git a/drivers/scsi/scsi_transport_iscsi.c
>> b/drivers/scsi/scsi_transport_iscsi.c
>> index 417b868d8735..7251b2b5b272 100644
>> --- a/drivers/scsi/scsi_transport_iscsi.c
>> +++ b/drivers/scsi/scsi_transport_iscsi.c
>> @@ -36,6 +36,12 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(iscsi_dbg_session);
>> EXPORT_TRACEPOINT_SYMBOL_GPL(iscsi_dbg_tcp);
>> EXPORT_TRACEPOINT_SYMBOL_GPL(iscsi_dbg_sw_tcp);
>>
>> +static bool kern_conn_failure;
>> +module_param(kern_conn_failure, bool, S_IRUGO|S_IWUSR);
>> +MODULE_PARM_DESC(kern_conn_failure,
>> + "Allow the kernel to detect and disable broken connections "
>> + "without requiring userspace intervention");
>> +
>> static int dbg_session;
>> module_param_named(debug_session, dbg_session, int,
>> S_IRUGO | S_IWUSR);
>> @@ -84,6 +90,12 @@ struct iscsi_internal {
>> struct transport_container session_cont;
>> };
>>
>> +/* Worker to perform connection failure on unresponsive connections
>> + * completely in kernel space.
>> + */
>> +static void stop_conn_work_fn(struct work_struct *work);
>> +static DECLARE_WORK(stop_conn_work, stop_conn_work_fn);
>> +
>> static atomic_t iscsi_session_nr; /* sysfs session id for next new session
>> */
>> static struct workqueue_struct *iscsi_eh_timer_workq;
>>
>> @@ -1609,6 +1621,7 @@ static DEFINE_MUTEX(rx_queue_mutex);
>> static LIST_HEAD(sesslist);
>> static DEFINE_SPINLOCK(sesslock);
>> static LIST_HEAD(connlist);
>> +static LIST_HEAD(connlist_err);
>> static DEFINE_SPINLOCK(connlock);
>>
>> static uint32_t iscsi_conn_get_sid(struct iscsi_cls_conn *conn)
>> @@ -2245,6 +2258,7 @@ iscsi_create_conn(struct iscsi_cls_session *session,
>> int dd_size, uint32_t cid)
>>
>> mutex_init(>ep_mutex);
>> INIT_LIST_HEAD(>conn_list);
>> +INIT_LIST_HEAD(>conn_list_err);
>> conn->transport = transport;
>> conn->cid = cid;
>>
>> @@ -2291,6 +2305,7 @@ int iscsi_destroy_conn(struct iscsi_cls_conn *conn)
>>
>> spin_lock_irqsave(, flags);
>> list_del(>conn_list);
>> +list_del(>conn_list_err);
>> spin_unlock_irqrestore(, flags);
>>
>> transport_unregister_device(>dev);
>> @@ -2405,6 +2420,28 @@ int iscsi_offload_mesg(struct Scsi_Host *shost,
>> }
>> EXPORT_SYMBOL_GPL(iscsi_offload_mesg);
>>
>> +static void stop_conn_work_fn(struct work_struct *work)
>> +{
>> +struct iscsi_cls_conn *conn, *tmp;
>> +unsigned long flags;
>> +LIST_HEAD(recovery_list);
>> +
>> +spin_lock_irqsave(, flags);
>> +if (list_empty(_err)) {
>> +spin_unlock_irqrestore(, flags);
>> +return;
>> +}
>> +list_splice_init(_err, _list);
>> +spin_unlock_irqrestore(, flags);
>> +
>> +mutex_lock(_queue_mutex);
>> +list_for_each_entry_safe(conn, tmp, _list, conn_list_err) {
>> +conn->transport->stop_conn(conn, STOP_CONN_RECOVER);
>> +list_del_init(>conn_list_err);
>> +}
>> +mutex_unlock(_queue_mutex);
>> +}
>> +
>> void iscsi_conn_error_event(struct iscsi_cls_conn *conn, enum iscsi_err
>> error)
>> {
>> struct nlmsghdr *nlh;
>> @@ -2412,6 +2449,15 @@ void iscsi_conn_error_event(struct iscsi_cls_conn
>> *conn, enum iscsi_err error)
>> struct iscsi_uevent *ev;
>> struct iscsi_internal *priv;
>> int len =
Re: [PATCH] iscsi: Perform connection failure entirely in kernel space
On 12/09/2019 12:20 PM, Gabriel Krisman Bertazi wrote:
> From: Bharath Ravi
>
> Connection failure processing depends on a daemon being present to (at
> least) stop the connection and start recovery. This is a problem on a
> multipath scenario, where if the daemon failed for whatever reason, the
> SCSI path is never marked as down, multipath won't perform the
> failover and IO to the device will be forever waiting for that
> connection to come back.
>
> This patch implements an optional feature in the iscsi module, to
> perform the connection failure inside the kernel. This way, the
> failover can happen and pending IO can continue even if the daemon is
> dead. Once the daemon comes alive again, it can perform recovery
> procedures if applicable.
>
> Co-developed-by: Dave Clausen
> Signed-off-by: Dave Clausen
> Co-developed-by: Nick Black
> Signed-off-by: Nick Black
> Co-developed-by: Vaibhav Nagarnaik
> Signed-off-by: Vaibhav Nagarnaik
> Co-developed-by: Anatol Pomazau
> Signed-off-by: Anatol Pomazau
> Co-developed-by: Tahsin Erdogan
> Signed-off-by: Tahsin Erdogan
> Co-developed-by: Frank Mayhar
> Signed-off-by: Frank Mayhar
> Co-developed-by: Junho Ryu
> Signed-off-by: Junho Ryu
> Co-developed-by: Khazhismel Kumykov
> Signed-off-by: Khazhismel Kumykov
> Signed-off-by: Bharath Ravi
> Co-developed-by: Gabriel Krisman Bertazi
> Signed-off-by: Gabriel Krisman Bertazi
> ---
> drivers/scsi/scsi_transport_iscsi.c | 46 +
> include/scsi/scsi_transport_iscsi.h | 1 +
> 2 files changed, 47 insertions(+)
>
> diff --git a/drivers/scsi/scsi_transport_iscsi.c
> b/drivers/scsi/scsi_transport_iscsi.c
> index 417b868d8735..7251b2b5b272 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -36,6 +36,12 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(iscsi_dbg_session);
> EXPORT_TRACEPOINT_SYMBOL_GPL(iscsi_dbg_tcp);
> EXPORT_TRACEPOINT_SYMBOL_GPL(iscsi_dbg_sw_tcp);
>
> +static bool kern_conn_failure;
> +module_param(kern_conn_failure, bool, S_IRUGO|S_IWUSR);
> +MODULE_PARM_DESC(kern_conn_failure,
> + "Allow the kernel to detect and disable broken connections "
> + "without requiring userspace intervention");
> +
> static int dbg_session;
> module_param_named(debug_session, dbg_session, int,
> S_IRUGO | S_IWUSR);
> @@ -84,6 +90,12 @@ struct iscsi_internal {
> struct transport_container session_cont;
> };
>
> +/* Worker to perform connection failure on unresponsive connections
> + * completely in kernel space.
> + */
> +static void stop_conn_work_fn(struct work_struct *work);
> +static DECLARE_WORK(stop_conn_work, stop_conn_work_fn);
> +
> static atomic_t iscsi_session_nr; /* sysfs session id for next new session */
> static struct workqueue_struct *iscsi_eh_timer_workq;
>
> @@ -1609,6 +1621,7 @@ static DEFINE_MUTEX(rx_queue_mutex);
> static LIST_HEAD(sesslist);
> static DEFINE_SPINLOCK(sesslock);
> static LIST_HEAD(connlist);
> +static LIST_HEAD(connlist_err);
> static DEFINE_SPINLOCK(connlock);
>
> static uint32_t iscsi_conn_get_sid(struct iscsi_cls_conn *conn)
> @@ -2245,6 +2258,7 @@ iscsi_create_conn(struct iscsi_cls_session *session,
> int dd_size, uint32_t cid)
>
> mutex_init(>ep_mutex);
> INIT_LIST_HEAD(>conn_list);
> + INIT_LIST_HEAD(>conn_list_err);
> conn->transport = transport;
> conn->cid = cid;
>
> @@ -2291,6 +2305,7 @@ int iscsi_destroy_conn(struct iscsi_cls_conn *conn)
>
> spin_lock_irqsave(, flags);
> list_del(>conn_list);
> + list_del(>conn_list_err);
> spin_unlock_irqrestore(, flags);
>
> transport_unregister_device(>dev);
> @@ -2405,6 +2420,28 @@ int iscsi_offload_mesg(struct Scsi_Host *shost,
> }
> EXPORT_SYMBOL_GPL(iscsi_offload_mesg);
>
> +static void stop_conn_work_fn(struct work_struct *work)
> +{
> + struct iscsi_cls_conn *conn, *tmp;
> + unsigned long flags;
> + LIST_HEAD(recovery_list);
> +
> + spin_lock_irqsave(, flags);
> + if (list_empty(_err)) {
> + spin_unlock_irqrestore(, flags);
> + return;
> + }
> + list_splice_init(_err, _list);
> + spin_unlock_irqrestore(, flags);
> +
> + mutex_lock(_queue_mutex);
> + list_for_each_entry_safe(conn, tmp, _list, conn_list_err) {
> + conn->transport->stop_conn(conn, STOP_CONN_RECOVER);
> + list_del_init(>conn_list_err);
> + }
> + mutex_unlock(_queue_mutex);
> +}
> +
> void iscsi_conn_error_event(struct iscsi_cls_conn *conn, enum iscsi_err
> error)
> {
> struct nlmsghdr *nlh;
> @@ -2412,6 +2449,15 @@ void iscsi_conn_error_event(struct iscsi_cls_conn
> *conn, enum iscsi_err error)
> struct iscsi_uevent *ev;
> struct iscsi_internal *priv;
> int len = nlmsg_total_size(sizeof(*ev));
> + unsigned long flags;
> +
> + if (kern_conn_failure) {
> + spin_lock_irqsave(, flags);
> +
Re: reboot hangs with "Reached target shutdown", who can help me?
Have you encountered such a problem? Could you give me some suggestions? Ulrich Windl 于2019年12月10日周二 下午10:31写道： > Hi! > > I think the problem is more related to systemd, rather than iscsi. > Personally I hate systemd, but you don't wnat to know that... > > Regards, > Ulrich > > >>> can zhu schrieb am 10.12.2019 um 15:25 in > Nachricht > <372db1a3-424d-4063-bcdb-ccb0b821d...@googlegroups.com>: > > os version: > > > > CentOS Linux release 7.4.1708 (Core) > > > > kernel version: > > > > 3.10.0-693.el7.x86_64 > > > > > > systemd version: > > > > *systemd*-219-42.el7.x86_64 > > > > > > Mount iscsi devices on the node(iscsi client node) and reboot os, hangs: > > > > [image: WechatIMG2178.png] > > > > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "open-iscsi" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to open-iscsi+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/open-iscsi/372db1a3-424d-4063-bcdb-ccb0b821 > > df0b%40googlegroups.com. > > > > > -- > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to open-iscsi+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/open-iscsi/5DEFAC4902A10003598D%40gwsmtp.uni-regensburg.de > . > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/CAGJK1Kk1LhxJHx0r9wVcfM4gjH8ypKnjHgu3Ne8cY_CcMkVhqw%40mail.gmail.com.
Antw: reboot hangs with "Reached target shutdown", who can help me?
Hi! I think the problem is more related to systemd, rather than iscsi. Personally I hate systemd, but you don't wnat to know that... Regards, Ulrich >>> can zhu schrieb am 10.12.2019 um 15:25 in Nachricht <372db1a3-424d-4063-bcdb-ccb0b821d...@googlegroups.com>: > os version: > > CentOS Linux release 7.4.1708 (Core) > > kernel version: > > 3.10.0-693.el7.x86_64 > > > systemd version: > > *systemd*-219-42.el7.x86_64 > > > Mount iscsi devices on the node(iscsi client node) and reboot os, hangs: > > [image: WechatIMG2178.png] > > > > > -- > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to open-iscsi+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/open-iscsi/372db1a3-424d-4063-bcdb-ccb0b821 > df0b%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/5DEFAC4902A10003598D%40gwsmtp.uni-regensburg.de.
reboot hangs with "Reached target shutdown", who can help me?
os version: CentOS Linux release 7.4.1708 (Core) kernel version: 3.10.0-693.el7.x86_64 systemd version: *systemd*-219-42.el7.x86_64 Mount iscsi devices on the node(iscsi client node) and reboot os, hangs: [image: WechatIMG2178.png] -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/372db1a3-424d-4063-bcdb-ccb0b821df0b%40googlegroups.com.
Re: Re: iSCSI packet generator
Like above, can you please give me more hints/clues in which other code(s) I need to see. Which part of this gigantic MQ-Block layer code base to see to understand the complete data flow? I am particularly interested in Hash , Map data structures. On Tuesday, December 10, 2019 at 11:34:49 AM UTC+1, Bobby wrote: > > > Perfect ! After this reply, I had to dig deeper and now it makes > sensethanks a lot The Lee-Man for explaining it so effectively... > > > On Saturday, November 9, 2019 at 7:52:52 PM UTC+1, The Lee-Man wrote: >> >> On Friday, November 8, 2019 at 10:40:08 AM UTC-8, Bobby wrote: >>> >>> >>> Hi Ulrich, >>> >>> Thanks for the hint. Can you please help me regarding following two >>> questions. >>> >>> - Linux block layer perform IO scheduling IO submissions to storage >>> device driver. If there is a physical device, the block layer interacts >>> with it through SCSI mid layer and SCSI low level drivers. So, how >>> *actually* a software initiator (*Open-iSCSI*) interacts with "*block >>> layer*"? >>> >>> - What confuses me, where does the "*disk driver*" comes into play? >>> >>> Thanks :-) >>> >>> >> In an iSCSI connection (session), there is the initiator and the target. >> I assume you are talking about the initiator. >> >> On the initiator, the "magic" is done by the kernel, in particular the >> iSCSI initiator code in the kernel, specifically by the >> scsi_transport_iscsi.c in drivers/scsi. When an iSCSI connection is made, >> the code creates a new "host" object, and then tests the device at the >> other end of the connection. If it's a disc drive, then an instance of sd >> is created (the disc driver). If the device is tape, a tape driver is >> instantiated (st). Unrecognized devices still get a generic SCSI device >> node, I believe. >> >> So, in this way, iSCSI is acting like an adapter driver, which plugs into >> the SCSI mid-layer. >> >> You can run "sudo journalctl -xe --follow" in one window, then log into >> an existing target in another (I used "sudo iscsiadm -m node -l"), and you >> should see this kind of output from journalctl: >> >> ... >> >> >> >>> Nov 09 10:46:59 linux-dell kernel: iscsi: registered transport (tcp) >>> Nov 09 10:46:59 linux-dell kernel: scsi host3: iSCSI Initiator over >>> TCP/IP >>> Nov 09 10:46:59 linux-dell iscsid[13175]: iscsid: Connection1:0 to >>> [target: iqn.2003-01.org.linux-iscsi.linux-dell.x8664:sn.2a6e21b1b53c, >>> portal: 192.168.20.3,3260] through [iface: default] is operational now >>> Nov 09 10:46:59 linux-dell kernel: scsi 3:0:0:0: Direct-Access >>> LIO-ORG test-disc4.0 PQ: 0 ANSI: 5 >>> Nov 09 10:46:59 linux-dell kernel: scsi 3:0:0:0: alua: supports implicit >>> and explicit TPGS >>> Nov 09 10:46:59 linux-dell kernel: scsi 3:0:0:0: alua: device >>> naa.6001405de01c6e7933b414e901e22b0f port group 0 rel port 1 >>> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: Attached scsi generic sg1 >>> type 0 >>> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] 2097152 512-byte >>> logical blocks: (1.07 GB/1.00 GiB) >>> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Write Protect is off >>> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Mode Sense: 43 00 >>> 10 08 >>> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Write cache: >>> enabled, read cache: enabled, supports DPO and FUA >>> Nov 09 10:46:59 linux-dell kernel: >>> iSCSI/iqn.1996-04.de.suse:01:54cab487975b: Unsupported SCSI Opcode 0xa3, >>> sending CHECK_CONDITION. >>> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Optimal transfer >>> size 8388608 bytes >>> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Attached SCSI disk >>> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: alua: transition timeout >>> set to 60 seconds >>> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: alua: port group 00 state >>> A non-preferred supports TOlUSNA >>> >>... >> >> -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/66d69bcc-1650-4df8-86dc-ad631d4da5c4%40googlegroups.com.
Re: Re: iSCSI packet generator
Perfect ! After this reply, I had to dig deeper and now it makes sensethanks a lot The Lee-Man for explaining it so effectively... On Saturday, November 9, 2019 at 7:52:52 PM UTC+1, The Lee-Man wrote: > > On Friday, November 8, 2019 at 10:40:08 AM UTC-8, Bobby wrote: >> >> >> Hi Ulrich, >> >> Thanks for the hint. Can you please help me regarding following two >> questions. >> >> - Linux block layer perform IO scheduling IO submissions to storage >> device driver. If there is a physical device, the block layer interacts >> with it through SCSI mid layer and SCSI low level drivers. So, how >> *actually* a software initiator (*Open-iSCSI*) interacts with "*block >> layer*"? >> >> - What confuses me, where does the "*disk driver*" comes into play? >> >> Thanks :-) >> >> > In an iSCSI connection (session), there is the initiator and the target. I > assume you are talking about the initiator. > > On the initiator, the "magic" is done by the kernel, in particular the > iSCSI initiator code in the kernel, specifically by the > scsi_transport_iscsi.c in drivers/scsi. When an iSCSI connection is made, > the code creates a new "host" object, and then tests the device at the > other end of the connection. If it's a disc drive, then an instance of sd > is created (the disc driver). If the device is tape, a tape driver is > instantiated (st). Unrecognized devices still get a generic SCSI device > node, I believe. > > So, in this way, iSCSI is acting like an adapter driver, which plugs into > the SCSI mid-layer. > > You can run "sudo journalctl -xe --follow" in one window, then log into an > existing target in another (I used "sudo iscsiadm -m node -l"), and you > should see this kind of output from journalctl: > > ... > > > >> Nov 09 10:46:59 linux-dell kernel: iscsi: registered transport (tcp) >> Nov 09 10:46:59 linux-dell kernel: scsi host3: iSCSI Initiator over TCP/IP >> Nov 09 10:46:59 linux-dell iscsid[13175]: iscsid: Connection1:0 to >> [target: iqn.2003-01.org.linux-iscsi.linux-dell.x8664:sn.2a6e21b1b53c, >> portal: 192.168.20.3,3260] through [iface: default] is operational now >> Nov 09 10:46:59 linux-dell kernel: scsi 3:0:0:0: Direct-Access >> LIO-ORG test-disc4.0 PQ: 0 ANSI: 5 >> Nov 09 10:46:59 linux-dell kernel: scsi 3:0:0:0: alua: supports implicit >> and explicit TPGS >> Nov 09 10:46:59 linux-dell kernel: scsi 3:0:0:0: alua: device >> naa.6001405de01c6e7933b414e901e22b0f port group 0 rel port 1 >> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: Attached scsi generic sg1 >> type 0 >> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] 2097152 512-byte >> logical blocks: (1.07 GB/1.00 GiB) >> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Write Protect is off >> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Mode Sense: 43 00 10 >> 08 >> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Write cache: >> enabled, read cache: enabled, supports DPO and FUA >> Nov 09 10:46:59 linux-dell kernel: >> iSCSI/iqn.1996-04.de.suse:01:54cab487975b: Unsupported SCSI Opcode 0xa3, >> sending CHECK_CONDITION. >> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Optimal transfer >> size 8388608 bytes >> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Attached SCSI disk >> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: alua: transition timeout >> set to 60 seconds >> Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: alua: port group 00 state >> A non-preferred supports TOlUSNA >> >... > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/bae3a7e2-306b-4959-9f8a-62bb6ae6fb00%40googlegroups.com.
