Re: [PATCH 4/4] mtd: nand: nandsim: convert to memalloc_noreclaim_*()
Michal, Am 05.04.2017 um 13:31 schrieb Michal Hocko: > On Wed 05-04-17 09:47:00, Vlastimil Babka wrote: >> Nandsim has own functions set_memalloc() and clear_memalloc() for robust >> setting and clearing of PF_MEMALLOC. Replace them by the new generic helpers. >> No functional change. > > This one smells like an abuser. Why the hell should read/write path > touch memory reserves at all! Could be. Let's ask Adrian, AFAIK he wrote that code. Adrian, can you please clarify why nandsim needs to play with PF_MEMALLOC? Thanks, //richard -- 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 post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Patch: It is not necessary to try to increase the priority of the wq thread from userspace
Hi folks,
We recently found that iscsid was iterating through /proc//stat
looking for the workqueue iscsi-q-NN and then setting its nice value
to -20.
Then we investigated some more because it seemed like this could be
more easily done from the kernel.
What we discovered is that with modern Linux kernels, at least since
3.10.0 and possibly earlier, the thread called is not the
actual workqueue thread, it is the rescue thread for the workqueue,
and it already runs at -20!
Indeed, the work items are handled on a pool of threads.
This patch removes that call and code as it is redundant and actually
causes things to take longer and is a problem when you are trying to
start hundreds of iSCSI sessions.
There is another patch for the LLD to use a WQ_HIGHPRI queue to
achieve the original intent.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
--
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 post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
From 86d76f1e6c52b8f3af26ec82667c626a63415a96 Mon Sep 17 00:00:00 2001
From: Richard Sharpe
Date: Wed, 30 Mar 2016 18:49:48 -0700
Subject: [PATCH] It is not necessary to change the priority of the processes
called [iscsi-q-NN] for a couple of reasons:
1. That process/thread already has a nice value of -20
2. It is the rescue thread associated with the workqueue created
for the iSCSI session, not the actual workqueue.
There is a separate patch to the iSCSI LLD that will make the
intended priority change.
Signed-off-by: Richard Sharpe
---
usr/initiator.c | 84 -
1 file changed, 84 deletions(-)
diff --git a/usr/initiator.c b/usr/initiator.c
index 8cd1896..3d380a2 100644
--- a/usr/initiator.c
+++ b/usr/initiator.c
@@ -1352,89 +1352,6 @@ static void session_conn_recv_pdu(void *data)
}
}
-static void session_increase_wq_priority(struct iscsi_session *session)
-{
- DIR *proc_dir;
- struct dirent *proc_dent;
- struct stat statb;
- char stat_file[PATH_SIZE];
- char sbuf[1024]; /* got this from ps */
- int pid, stat_fd, num_read;
- char *proc_name, *proc_name_end;
- uint32_t host_no;
-
- /* drivers like bnx2i and qla4xxx do not have a write wq */
- if (session->t->caps & CAP_DATA_PATH_OFFLOAD)
- return;
-
- proc_dir = opendir(PROC_DIR);
- if (!proc_dir)
- goto fail;
-
- while ((proc_dent = readdir(proc_dir))) {
- if (!strcmp(proc_dent->d_name, ".") ||
- !strcmp(proc_dent->d_name, ".."))
- continue;
- if (sscanf(proc_dent->d_name, "%d", &pid) != 1)
- continue;
-
- memset(stat_file, 0, sizeof(stat_file));
- sprintf(stat_file, PROC_DIR"/%d/stat", pid);
- if (stat(stat_file, &statb))
- continue;
-
- if (!S_ISREG( statb.st_mode))
- continue;
-
- stat_fd = open(stat_file, O_RDONLY);
- if (stat_fd == -1)
- continue;
-
- memset(sbuf, 0, sizeof(sbuf));
- num_read = read(stat_fd, sbuf, sizeof(sbuf));
- close(stat_fd);
- if (num_read == -1)
- continue;
- if (num_read == sizeof(sbuf))
- sbuf[num_read - 1] = '\0';
- else
- sbuf[num_read] = '\0';
-
- /*
- * Finally match proc name to iscsi thread name.
- * In newer kernels the name is iscsi_wq_%HOST_NO.
- * In older kernels before 2.6.30, it was scsi_wq_%HOST_NO.
- *
- * We only support newer kernels.
- */
- proc_name = strchr(sbuf, '(') + 1;
- if (!proc_name)
- continue;
-
- proc_name_end = strchr(proc_name, ')');
- if (!proc_name_end)
- continue;
-
- *proc_name_end = '\0';
-
- if (sscanf(proc_name, "iscsi_q_%u\n", &host_no) == 1) {
- if (host_no == session->hostno) {
-if (!setpriority(PRIO_PROCESS, pid,
- session->nrec.session.xmit_thread_priority)) {
- closedir(proc_dir);
- return;
-} else
- break;
- }
- }
- }
- closedir(proc_dir);
-fail:
- log_error("Could not set session%d priority. "
- "READ/WRITE throughout and latency could be "
- "affected.", session->id);
-}
-
static int session_ipc_create(struct iscsi_session *session)
{
struct iscsi_conn *conn = &session->conn[0];
@@ -1463,7 +1380,6 @@ retry_create:
if (!err) {
session->hostno = host_no;
- session_increase_wq_priority(session);
}
return err;
}
--
2.4.3
Corruption of config files causing
What seems to be happening is that the config files are getting corrupted in interesting ways such that they have more than 2048 chars in a line without an NL. Eg: --- /var/lib/iscsi/nodes/iqn.2010-06.com.nutanix:volumegroup- d86fb4c6-0a26-4a99-a4c4-38966b1955c8/10.5.20.138,3260, 1^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@# BEGIN RECORD 6.2.0-873.13.el6 node.name = iqn.2010-06.com.nutanix:volumegroup-5bd06b21-fb06- 4b8e-b973-e81b86409e39 -- There are other cases. Some where both of the first two lines are two long or where the second line is missing. This then causes errors like this: iscsiadm: Could not stat /var/lib/iscsi/nodes//,3260,-1 /default to delete node err 2\n\niscsiadm: Could not add/update [tcp:[hw=,ip=,net_if=,iscsi_if=default] 10.35.65.25,3260,1 scale_sd2] I hear that there might be a patch to fix this problem. Can anyone point me at it? -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. T
Re: Problem with auto-starup on Debian 6
On Thu, 2013-01-10 at 00:24 -0600, Mike Christie wrote: > I think some > distros just call iscsi anytime there is a network change like a > interface coming up or a interface getting a address. Ubuntu (and I'd guess Debian) does this (well, the on ifup part). It also stops open-iscsi on ifdown. I just had to disable that today. Imagine a virtualization host server. You create a new VM on a new VLAN. You add the relevant bridge interface, bring it up, and *bam*, all your existing, running VMs just lost access to their disks. Likewise, you can't upgrade the open-iscsi package while anything is using iSCSI devices, because it will stop and start the service. I solved these problems by using dpkg-divert on the if-up.d and if-down.d scripts to move them to open-iscsi.disabled and a custom policy-rc.d script to disallow open-iscsi stops or restarts if any VMs are running. Also, at least in my case, it's necessary to restart libvirt-bin after restarting open-iscsi. Are many people really using iSCSI via roaming network connectivity? -- Richard signature.asc Description: This is a digitally signed message part
Re: Disabling startup on Centos 5.8
Hi, Thanks for your help, resolved the issue now. It had been setup to load the kernel modules and mount the target via the initrd image. I can't tell you how frustrating that was to diagnose :) I removed the offending lines, rebuilt the image, then fixed the issue. Regards R On Friday, November 2, 2012 3:42:41 PM UTC, Mike Christie wrote: > > On 11/01/2012 04:19 PM, ric...@aggress.net wrote: > > Hi, > > > > My iSCSI target is broken and I need to disable open-iscsi from starting > > up as it sits in a loop trying to connect without timing out. > > > Are you sure it does not timeout? The default timeout is long, but it > should timeout eventually. Did you change it? > > What is the errors in the log? > > > > > However.. I'm seemingly unable to do this.. > > > > I've disabled all services via chkconfig and confirmed in each rc*.d > > directory > > Did you chkconfig iscsid and iscsi services? > > > > > Rebooted, it still comes up and tries to connect to the broken node > > > > I've set node.startup = manual in both /etc/iscsi/iscsid.conf and in the > > node itself > > > > I've rm -rf /var/lib/iscsi/* > > If you do not have any files in there then there is nothing for iscsi to > login to. > > I think Misha might be right. What is in > > /proc/cmdline > > ? > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To view this discussion on the web visit https://groups.google.com/d/msg/open-iscsi/-/aOQjjReP4mQJ. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Disabling startup on Centos 5.8
Hi, My iSCSI target is broken and I need to disable open-iscsi from starting up as it sits in a loop trying to connect without timing out. However.. I'm seemingly unable to do this.. I've disabled all services via chkconfig and confirmed in each rc*.d directory Rebooted, it still comes up and tries to connect to the broken node I've set node.startup = manual in both /etc/iscsi/iscsid.conf and in the node itself I've rm -rf /var/lib/iscsi/* Rebooted, still comes up and tries to connect to the same node. Please can someone advise how best to disable this service from starting? Thanks Richard -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To view this discussion on the web visit https://groups.google.com/d/msg/open-iscsi/-/wWLrESe0kTgJ. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: LU Alias
All `sg_vpd --page=0x83` returns is the IQN: Device Identification VPD page: Addressed logical unit: designator type: NAA, code set: Binary 0x600144f0e431c9004fe3632f0003 Target port: designator type: vendor specific [0x0], code set: ASCII transport: Internet SCSI (iSCSI) vendor specific: iqn.1999-03.com.wiktel:01:krls1 designator type: Target port group, code set: Binary Target port group: 0x0 designator type: Relative target port, code set: Binary Relative target port: 0x2 I'm thinking that OpenIndiana/Illumos/COMSTAR/whatever-component isn't actually exporting this information in any way. -- Richard -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: LU Alias
On Thu, 2012-05-10 at 12:21 -0500, Mike Christie wrote: > A netapp engineer suggested trying the "REPORT IDENTIFYING INFORMATION" > command. To do this you can use sg_ident from the sg3_utils. $ sudo sg_ident -i 127 /dev/sdm Information type: 0, Maximum information length: 0 bytes Information type: 4, Maximum information length: 256 bytes The only one it could be is 4, since the LU alias field is 255 characters, I think. But here are both: $ sudo sg_ident -i 0 /dev/sdm $ sudo sg_ident -i 4 /dev/sdm bad field in Report identifying information cdb including unsupported service action -- Richard signature.asc Description: This is a digitally signed message part
Re: LU Alias
I'm really referring to the LU alias. I asked about this in #illumos (on freenode). After that discussion, I'm not sure that it's even exposed by the target. Is there an obvious place in the VPD (page 0x80, 0x83, ???) where it should be exported? If so, maybe this is just an issue for the Illumos side. -- Richard signature.asc Description: This is a digitally signed message part
LU Alias
I'm using open-iscsi to connect to an OpenIndiana COMSTAR target. I have aliases set on the LUs on the COMSTAR side. Is there a way to retrieve those from open-iscsi? (I'd like to have a udev rule to give me nice names.) -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
how to find target devices that are not on local machine
I'm installing open-iscsi on a dell NX1950 w/ an MD3000. I was able to start a target daemon as well as an initiator. My problem is that I can't seem to find my target disks so that I can partition them and create the file systems. Or maybe I'm not discovering targets correctly and therefore have wrong info in /etc/ ietd.conf. Hopefully the info below will help. $ sudo /etc/init.d/ietd start * net.core.rmem_max (131071) is lower than recommended 1048576 * net.core.rmem_default (122880) is lower than recommended 1048576 * net.core.wmem_max (131071) is lower than recommended 1048576 * net.core.wmem_default (122880) is lower than recommended 1048576 * net.ipv4.tcp_mem:min (380256) is lower than recommended 1048576 * net.ipv4.tcp_mem:default (507008) is lower than recommended 1048576 * net.ipv4.tcp_mem:max (760512) is lower than recommended 1048576 * net.ipv4.tcp_rmem:min (4096) is lower than recommended 1048576 * net.ipv4.tcp_rmem:default (87380) is lower than recommended 1048576 * net.ipv4.tcp_wmem:min (4096) is lower than recommended 1048576 * net.ipv4.tcp_wmem:default (16384) is lower than recommended 1048576 * Loading iSCSI-Target modules - iscsi_trgt ... [ ok ] * Starting iSCSI Enterprise Target ... [ ok ] $ sudo /etc/init.d/iscsid start * Checking open-iSCSI configuration ... * Loading iSCSI modules ... * Loading libiscsi ... [ ok ] * Loading scsi_transport_iscsi ... [ ok ] * Loading iscsi_tcp ... [ ok ] * Starting iscsid ... * Setting up iSCSI targets ... iscsiadm: No records found! [ !! ] … but issuing this command again makes everything pass. $ sudo /etc/init.d/iscsid start * Checking open-iSCSI configuration ... * Loading iSCSI modules ... * Loading libiscsi ... [ ok ] * Loading scsi_transport_iscsi ... [ ok ] * Loading iscsi_tcp ... [ ok ] * Starting iscsid ... $ sudo /usr/sbin/iscsiadm -m discovery -t st -p 192.168.20.12 -P1 Target: iqn.2011-03.local.mydomain.batman:storage.rack1.disk1 Portal: 192.168.20.12:3260,1 Iface Name: default $ cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 08 Lun: 00 Vendor: DP Model: BACKPLANERev: 1.05 Type: EnclosureANSI SCSI revision: 05 Host: scsi0 Channel: 02 Id: 00 Lun: 00 Vendor: DELL Model: PERC 5/i Rev: 1.03 Type: Direct-AccessANSI SCSI revision: 05 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: SONY Model: DVD-ROM DDU810A Rev: KD38 Type: CD-ROM ANSI SCSI revision: 05 Host: scsi3 Channel: 00 Id: 00 Lun: 00 Vendor: Dell Model: Virtual CDROM Rev: 123 Type: CD-ROM ANSI SCSI revision: 00 Host: scsi4 Channel: 00 Id: 00 Lun: 00 Vendor: Dell Model: Virtual Floppy Rev: 123 Type: Direct-AccessANSI SCSI revision: 00 The Dell NS1950 has two SAS disks, sda, sda1, sda2, sda3, etc... and sdb. There are about 10 disks in the MD3000 cabinet I'm trying to reach but don't know how to get to. I think once I know the /dev/xxx path, I could then put that into the ietd.conf file as targets and my iscsiadm discovery would then find them. In /etc/ietd.conf I have the following path Lun 0 Path=/dev/sdc,Type=fileio Can anyone offer help here? -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: OpenSuse 10sp3 conn error
I also notice the error occured about 7 minutes,why? Oct 6 23:55:03 linux-j2cx iscsid: can not send nopin response Oct 7 00:01:36 linux-j2cx iscsid: can not send nopin response Oct 7 00:08:09 linux-j2cx iscsid: can not send nopin response Oct 7 00:14:41 linux-j2cx iscsid: can not send nopin response Oct 7 00:21:14 linux-j2cx iscsid: can not send nopin response Oct 7 00:27:47 linux-j2cx iscsid: can not send nopin response Oct 7 00:34:20 linux-j2cx iscsid: can not send nopin response On Oct 6, 5:06 pm, Richard <[EMAIL PROTECTED]> wrote: > Mike, there is the log, it's create by foreground with debug level 8: > (This log iscsid verison is 2.0.869) > > iscsid: get conn context 0x63c050 > iscsid: message real length is 120 bytes, recv_handle 0x63d950 > iscsid: in nlpayload_read > iscsid: sched conn context 0x63c050 event 1, tmo 0 > iscsid: thread 0x63c050 schedule: delay 0 state 3 > iscsid: exec thread 0063c050 callback > iscsid: in krecv_pdu_begin > iscsid: recv PDU began, pdu handle 0x0x63d988 > iscsid: in kread > iscsid: read 48 bytes of PDU header > iscsid: read 48 PDU header bytes, opcode 0x20, dlength 0, data > 0x637af0, max 8192 > iscsid: in krecv_pdu_end > iscsid: recv PDU finished for pdu handle 0x0x63d988 > iscsid: put conn context 0x63c050 > iscsid: sending Nop-out pdu with ttt 420002, CmdSN 0: > iscsid: in ksend_pdu_begin > iscsid: send PDU began for hdr 48 bytes and data 0 bytes > iscsid: in kwritev > iscsid: wrote 48 bytes of PDU header > iscsid: in ksend_pdu_end > iscsid: in __kipc_call > iscsid: in kwritev > iscsid: in nlpayload_read > iscsid: in nlpayload_read > ***iscsid: can not send nopin response > iscsid: thread removed > > ... ... > > iscsid: login response status 0101 > iscsid: login_rsp ret (8) > iscsid: login redirect ... > > iscsid: re-opening session 1 (reopen_cnt 1) > ... ... > > iscsid: set operational parameter 25 to: > iscsid: > iscsid: in kset_param > iscsid: in __kipc_call > iscsid: in kwritev > iscsid: in nlpayload_read > > iscsid: expecting event 16, got 103, handling... > iscsid: in nlpayload_read > iscsid: received iferror -38 > iscsid: set operational parameter 26 to: > iscsid: 1 > iscsid: in kset_param > iscsid: in __kipc_call > iscsid: in kwritev > iscsid: in nlpayload_read > ***iscsid: expecting event 16, got 103, handling... > iscsid: in nlpayload_read > iscsid: received iferror -38 > iscsid: set operational parameter 27 to: > iscsid: 15 > iscsid: in kset_param > iscsid: in __kipc_call > iscsid: in kwritev > iscsid: in nlpayload_read > iscsid: expecting event 16, got 103, handling... > iscsid: in nlpayload_read > iscsid: received iferror -38 > iscsid: set operational parameter 28 to: > iscsid: 20 > iscsid: in kset_param > iscsid: in __kipc_call > iscsid: in kwritev > iscsid: in nlpayload_read > iscsid: expecting event 16, got 103, handling... > iscsid: in nlpayload_read > iscsid: received iferror -38 > iscsid: set operational parameter 30 to: > iscsid: 5 > iscsid: in kset_param > iscsid: in __kipc_call > iscsid: in kwritev > iscsid: in nlpayload_read > iscsid: expecting event 16, got 103, handling... > iscsid: in nlpayload_read > iscsid: received iferror -38 > iscsid: set operational parameter 31 to: > iscsid: 5 > iscsid: in kset_host_param > iscsid: in __kipc_call > iscsid: in kwritev > iscsid: in nlpayload_read > iscsid: in nlpayload_read > iscsid: set operational parameter 1 to: > iscsid: iqn.2005-03.org.open-iscsi:3f5b812c71dd > iscsid: in kset_host_param > iscsid: in __kipc_call > iscsid: in kwritev > iscsid: in nlpayload_read > iscsid: in nlpayload_read > iscsid: set operational parameter 2 to: > iscsid: default > iscsid: in kset_host_param > iscsid: in __kipc_call > iscsid: in kwritev > iscsid: in nlpayload_read > iscsid: in nlpayload_read > iscsid: set operational parameter 0 to: > iscsid: default > iscsid: in kstart_conn > iscsid: in __kipc_call > iscsid: in kwritev > iscsid: in nlpayload_read > iscsid: in nlpayload_read > iscsid: online device using /sys/bus/scsi/devices/6:0:0:0/state > iscsid: mgmt_ipc_write_rsp: rsp to fd -1 > iscsid: connection1:0 is operational after recovery (1 attempts) > iscsid: thread 0x639f38 schedule: delay 20 state 3 > iscsid: noop out timer 0x639f38 start > > On Oct 4, 9:56 pm, Richard <[EMAIL PROTECTED]> wrote: > > > Thanks,I think need use it. > > On Oct 3, 1:42 am, Mike Christie <[EMAIL PROTECTED]> wrote: > > > > Richard wrote: > > > > 71686 Sep 26 22:36:47 linux-j2cx kernel: connection1:0: iscsi: > > > > detected conn error (1011) > > > > 71687 S
Re: OpenSuse 10sp3 conn error
Mike, there is the log, it's create by foreground with debug level 8: (This log iscsid verison is 2.0.869) iscsid: get conn context 0x63c050 iscsid: message real length is 120 bytes, recv_handle 0x63d950 iscsid: in nlpayload_read iscsid: sched conn context 0x63c050 event 1, tmo 0 iscsid: thread 0x63c050 schedule: delay 0 state 3 iscsid: exec thread 0063c050 callback iscsid: in krecv_pdu_begin iscsid: recv PDU began, pdu handle 0x0x63d988 iscsid: in kread iscsid: read 48 bytes of PDU header iscsid: read 48 PDU header bytes, opcode 0x20, dlength 0, data 0x637af0, max 8192 iscsid: in krecv_pdu_end iscsid: recv PDU finished for pdu handle 0x0x63d988 iscsid: put conn context 0x63c050 iscsid: sending Nop-out pdu with ttt 420002, CmdSN 0: iscsid: in ksend_pdu_begin iscsid: send PDU began for hdr 48 bytes and data 0 bytes iscsid: in kwritev iscsid: wrote 48 bytes of PDU header iscsid: in ksend_pdu_end iscsid: in __kipc_call iscsid: in kwritev iscsid: in nlpayload_read iscsid: in nlpayload_read ***iscsid: can not send nopin response iscsid: thread removed ... ... iscsid: login response status 0101 iscsid: login_rsp ret (8) iscsid: login redirect ... iscsid: re-opening session 1 (reopen_cnt 1) ... ... iscsid: set operational parameter 25 to: iscsid: iscsid: in kset_param iscsid: in __kipc_call iscsid: in kwritev iscsid: in nlpayload_read iscsid: expecting event 16, got 103, handling... iscsid: in nlpayload_read iscsid: received iferror -38 iscsid: set operational parameter 26 to: iscsid: 1 iscsid: in kset_param iscsid: in __kipc_call iscsid: in kwritev iscsid: in nlpayload_read ***iscsid: expecting event 16, got 103, handling... iscsid: in nlpayload_read iscsid: received iferror -38 iscsid: set operational parameter 27 to: iscsid: 15 iscsid: in kset_param iscsid: in __kipc_call iscsid: in kwritev iscsid: in nlpayload_read iscsid: expecting event 16, got 103, handling... iscsid: in nlpayload_read iscsid: received iferror -38 iscsid: set operational parameter 28 to: iscsid: 20 iscsid: in kset_param iscsid: in __kipc_call iscsid: in kwritev iscsid: in nlpayload_read iscsid: expecting event 16, got 103, handling... iscsid: in nlpayload_read iscsid: received iferror -38 iscsid: set operational parameter 30 to: iscsid: 5 iscsid: in kset_param iscsid: in __kipc_call iscsid: in kwritev iscsid: in nlpayload_read iscsid: expecting event 16, got 103, handling... iscsid: in nlpayload_read iscsid: received iferror -38 iscsid: set operational parameter 31 to: iscsid: 5 iscsid: in kset_host_param iscsid: in __kipc_call iscsid: in kwritev iscsid: in nlpayload_read iscsid: in nlpayload_read iscsid: set operational parameter 1 to: iscsid: iqn.2005-03.org.open-iscsi:3f5b812c71dd iscsid: in kset_host_param iscsid: in __kipc_call iscsid: in kwritev iscsid: in nlpayload_read iscsid: in nlpayload_read iscsid: set operational parameter 2 to: iscsid: default iscsid: in kset_host_param iscsid: in __kipc_call iscsid: in kwritev iscsid: in nlpayload_read iscsid: in nlpayload_read iscsid: set operational parameter 0 to: iscsid: default iscsid: in kstart_conn iscsid: in __kipc_call iscsid: in kwritev iscsid: in nlpayload_read iscsid: in nlpayload_read iscsid: online device using /sys/bus/scsi/devices/6:0:0:0/state iscsid: mgmt_ipc_write_rsp: rsp to fd -1 iscsid: connection1:0 is operational after recovery (1 attempts) iscsid: thread 0x639f38 schedule: delay 20 state 3 iscsid: noop out timer 0x639f38 start On Oct 4, 9:56 pm, Richard <[EMAIL PROTECTED]> wrote: > Thanks,I think need use it. > On Oct 3, 1:42 am, Mike Christie <[EMAIL PROTECTED]> wrote: > > > Richard wrote: > > > 71686 Sep 26 22:36:47 linux-j2cx kernel: connection1:0: iscsi: > > > detected conn error (1011) > > > 71687 Sep 26 22:36:48 linux-j2cx iscsid: poll result 1 > > > 71688 Sep 26 22:36:48 linux-j2cx iscsid: in ctldev_handle > > > 71689 Sep 26 22:36:48 linux-j2cx iscsid: in nl_read > > > 71690 Sep 26 22:36:48 linux-j2cx iscsid: ctldev_handle got event type > > > 102 > > > 71691 Sep 26 22:36:48 linux-j2cx iscsid: get conn context 0x63ad00 > > > 71692 Sep 26 22:36:48 linux-j2cx iscsid: message real length is 72 > > > bytes, recv_handle 0x63c600 > > > 71693 Sep 26 22:36:48 linux-j2cx iscsid: in nlpayload_read > > > 71694 Sep 26 22:36:48 linux-j2cx iscsid: sched conn context 0x63ad00 > > > event 3, tmo 0 > > > 71695 Sep 26 22:36:48 linux-j2cx iscsid: thread 0x63ad00 schedule: > > > delay 0 state 3 > > > 71696 Sep 26 22:36:48 linux-j2cx iscsid: exec thread 0063ad00 callback > > > 71697 Sep 26 22:36:48 linux-j2cx iscsid: Kernel reported iSCSI > > > connection 1:0 error (1011) state (3) > > > I am sorry to make this difficult, but I need a little before this. > > > I am looking for the, "can not send nopin respons" message and then the > > stuf
Re: OpenSuse 10sp3 conn error
71969 Sep 26 22:36:49 linux-j2cx iscsid: >FirstBurstLength=65536 71970 Sep 26 22:36:49 linux-j2cx iscsid: >MaxConnections=1 71971 Sep 26 22:36:49 linux-j2cx iscsid: >MaxOutstandingR2T=1 71972 Sep 26 22:36:49 linux-j2cx iscsid: >OFMarker=No 71973 Sep 26 22:36:49 linux-j2cx iscsid: > MaxRecvDataSegmentLength=65536 71974 Sep 26 22:36:49 linux-j2cx iscsid: >TargetAlias=vol1 71975 Sep 26 22:36:49 linux-j2cx iscsid: >TargetPortalGroupTag=1 71976 Sep 26 22:36:49 linux-j2cx iscsid: in krecv_pdu_end 71977 Sep 26 22:36:49 linux-j2cx iscsid: recv PDU finished for pdu handle 0x0x63c638 71978 Sep 26 22:36:49 linux-j2cx iscsid: put conn context 0x63ad00 71979 Sep 26 22:36:49 linux-j2cx iscsid: login response status 71980 Sep 26 22:36:49 linux-j2cx iscsid: thread 00638db0 delete: state 1 71981 Sep 26 22:36:49 linux-j2cx iscsid: deleting a scheduled/waiting thread! 71982 Sep 26 22:36:49 linux-j2cx iscsid: in kset_param 71983 Sep 26 22:36:49 linux-j2cx iscsid: in __kipc_call 71984 Sep 26 22:36:49 linux-j2cx iscsid: in kwritev 71985 Sep 26 22:36:49 linux-j2cx iscsid: in nlpayload_read 71986 Sep 26 22:36:49 linux-j2cx iscsid: in nlpayload_read 71987 Sep 26 22:36:49 linux-j2cx iscsid: set operational parameter 0 to: 71988 Sep 26 22:36:49 linux-j2cx iscsid: 131072 71989 Sep 26 22:36:49 linux-j2cx iscsid: in kset_param 71990 Sep 26 22:36:49 linux-j2cx iscsid: in __kipc_call 71991 Sep 26 22:36:49 linux-j2cx iscsid: in kwritev 71992 Sep 26 22:36:49 linux-j2cx iscsid: in nlpayload_read 71993 Sep 26 22:36:49 linux-j2cx iscsid: in nlpayload_read 71994 Sep 26 22:36:49 linux-j2cx iscsid: set operational parameter 1 to: 71995 Sep 26 22:36:49 linux-j2cx iscsid: 65536 71996 Sep 26 22:36:49 linux-j2cx iscsid: in kset_param 71997 Sep 26 22:36:49 linux-j2cx iscsid: in __kipc_call 71998 Sep 26 22:36:49 linux-j2cx iscsid: in kwritev 71999 Sep 26 22:36:49 linux-j2cx iscsid: in nlpayload_read 72000 Sep 26 22:36:49 linux-j2cx iscsid: in nlpayload_read 72001 Sep 26 22:36:49 linux-j2cx iscsid: set operational parameter 2 to: 72002 Sep 26 22:36:49 linux-j2cx iscsid: 0 72003 Sep 26 22:36:49 linux-j2cx iscsid: in kset_param 72004 Sep 26 22:36:49 linux-j2cx iscsid: in __kipc_call 72005 Sep 26 22:36:49 linux-j2cx iscsid: in kwritev 72006 Sep 26 22:36:49 linux-j2cx iscsid: in nlpayload_read 72007 Sep 26 22:36:49 linux-j2cx iscsid: in nlpayload_read 72008 Sep 26 22:36:49 linux-j2cx iscsid: set operational parameter 3 to: ,, On Oct 1, 1:07 am, Mike Christie <[EMAIL PROTECTED]> wrote: > Richard wrote: > > Thanks. Yes,I also do it. The parameter only turn off iSCSI pings > > test, log show error from kernel,iscsid can only response reopen > > action.The debug infomation show: > > 71686 Sep 26 22:36:47 linux-j2cx kernel: connection1:0: iscsi: > > detected conn error (1011) > > I actually need the log before this part. At this line the error has > already happend. Feel free to dump as much log as you can. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: OpenSuse 10sp3 conn error
Thanks. Yes,I also do it. The parameter only turn off iSCSI pings test, log show error from kernel,iscsid can only response reopen action.The debug infomation show: 71686 Sep 26 22:36:47 linux-j2cx kernel: connection1:0: iscsi: detected conn error (1011) 71687 Sep 26 22:36:48 linux-j2cx iscsid: poll result 1 71688 Sep 26 22:36:48 linux-j2cx iscsid: in ctldev_handle 71689 Sep 26 22:36:48 linux-j2cx iscsid: in nl_read 71690 Sep 26 22:36:48 linux-j2cx iscsid: ctldev_handle got event type 102 71691 Sep 26 22:36:48 linux-j2cx iscsid: get conn context 0x63ad00 71692 Sep 26 22:36:48 linux-j2cx iscsid: message real length is 72 bytes, recv_handle 0x63c600 71693 Sep 26 22:36:48 linux-j2cx iscsid: in nlpayload_read 71694 Sep 26 22:36:48 linux-j2cx iscsid: sched conn context 0x63ad00 event 3, tmo 0 71695 Sep 26 22:36:48 linux-j2cx iscsid: thread 0x63ad00 schedule: delay 0 state 3 71696 Sep 26 22:36:48 linux-j2cx iscsid: exec thread 0063ad00 callback 71697 Sep 26 22:36:48 linux-j2cx iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3) 71698 Sep 26 22:36:48 linux-j2cx iscsid: put conn context 0x63ad00 71699 Sep 26 22:36:48 linux-j2cx iscsid: re-opening session 1 (reopen_cnt 1) 71700 Sep 26 22:36:48 linux-j2cx iscsid: thread 00638db0 delete: state 3 71701 Sep 26 22:36:48 linux-j2cx iscsid: thread 00638de8 delete: state 1 71702 Sep 26 22:36:48 linux-j2cx iscsid: deleting a scheduled/waiting thread! 71703 Sep 26 22:36:48 linux-j2cx iscsid: in kstop_conn 71704 Sep 26 22:36:48 linux-j2cx iscsid: in __kipc_call 71705 Sep 26 22:36:48 linux-j2cx iscsid: in kwritev 71706 Sep 26 22:36:48 linux-j2cx iscsid: in nlpayload_read 71707 Sep 26 22:36:48 linux-j2cx iscsid: in nlpayload_read 71708 Sep 26 22:36:48 linux-j2cx iscsid: connection 1:0 is stopped for recovery 71709 Sep 26 22:36:48 linux-j2cx iscsid: disconnecting conn 0x636900, fd 9 71710 Sep 26 22:36:48 linux-j2cx iscsid: get conn context 0x63ad00 71711 Sep 26 22:36:48 linux-j2cx iscsid: set TCP recv window size to 524288, actually got 262142 71712 Sep 26 22:36:48 linux-j2cx iscsid: set TCP send window size to 524288, actually got 262142 71713 Sep 26 22:36:48 linux-j2cx iscsid: connecting to 192.168.1.80:3260 71714 Sep 26 22:36:48 linux-j2cx iscsid: sched conn context 0x63ad00 event 2, tmo 0 71715 Sep 26 22:36:48 linux-j2cx iscsid: thread 0x63ad00 schedule: delay 0 state 3 71716 Sep 26 22:36:48 linux-j2cx iscsid: Setting login timer 0x638db0 timeout 15 71717 Sep 26 22:36:48 linux-j2cx iscsid: thread 0x638db0 schedule: delay 60 state 3 71718 Sep 26 22:36:48 linux-j2cx iscsid: thread 0x681418 10172 10222 71719 Sep 26 22:36:48 linux-j2cx kernel: connection2:0: iscsi: detected conn error (1011) 71720 Sep 26 22:36:48 linux-j2cx iscsid: thread removed 71721 Sep 26 22:36:48 linux-j2cx iscsid: thread 0063ad00 removed from poll_list 71722 Sep 26 22:36:48 linux-j2cx iscsid: thread 00681418 wait some more 71724 Sep 26 22:36:48 linux-j2cx iscsid: exec thread 0063ad00 callback 71725 Sep 26 22:36:48 linux-j2cx iscsid: put conn context 0x63ad00 71726 Sep 26 22:36:48 linux-j2cx iscsid: connected local port 34276 to 192.168.1.80:3260 71727 Sep 26 22:36:48 linux-j2cx iscsid: in kbind_conn 71728 Sep 26 22:36:48 linux-j2cx iscsid: in __kipc_call 71729 Sep 26 22:36:48 linux-j2cx iscsid: in kwritev 71730 Sep 26 22:36:48 linux-j2cx iscsid: in nlpayload_read 71731 Sep 26 22:36:48 linux-j2cx iscsid: in nlpayload_read 71732 Sep 26 22:36:48 linux-j2cx iscsid: bound iSCSI connection 1:0 to session 1 71733 Sep 26 22:36:48 linux-j2cx iscsid: sending login PDU with current stage 1, next stage 3, transit 0x80, isid 0x00023d01 exp_statsn 41145 On Sep 30, 12:36 am, [EMAIL PROTECTED] wrote: > On Sep 27, 9:26 am, iscsiFans <[EMAIL PROTECTED]> wrote: > > > Hi,all, > > I have install Opensuse 10sp3 (x86_64)+ Open-iscsi 2.865(iscsid) + > > Multipath-tools-0.4.7-80, Config and login is ok but I find /var/log/ > > messages have many conne error, so multipath is change-link many > > times, sometime when conn error, the server is hang, such as: > > iscsid v2.0.866 > > Sep 26 11:49:34 linux-j2cx iscsid: can not send nopin response > > I try to change the noop_timeout parameter, But it's no use: > > I do not think changing that value will help in this case, because > above the target is sending us a nop and we are trying to respond to > it. For some reason we are failing on sending a response the targets > nop. > > What target are you using btw? > > If you could run iscsid by hand with debugging by doing > > # iscsid -d 8 -f & > > we can see why it is failing. You might need to stop the iscsi > service, then run > > # iscsiad -d 8 -f & > # iscsiadm -m node -L automatic > > or instead of the last command you can log into a specific target by > doing > > iscsiadm -m node -T target -p ip -l > > Send all the out put from the iscsid. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to
