Re: [PATCH 08/23] ufs-exynos: move setting the the dma alignment to the init method
On 3/24/24 16:54, Christoph Hellwig wrote: Use the SCSI host's dma_alignment field and set it in ->init and remove the now unused config_scsi_dev method. Reviewed-by: Bart Van Assche -- 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/a81db761-7ed2-4e4b-834f-7641f6199fcc%40acm.org.
Re: [PATCH 07/23] scsi: add a dma_alignment field to the host and host template
On 3/24/24 16:54, Christoph Hellwig wrote: Get drivers out of the business of having to call the block layer dma alignment limits helpers themselves. Reviewed-by: Bart Van Assche -- 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/47028fba-7fb0-4eda-81a2-ccf439cfec6a%40acm.org.
Re: [PATCH 09/23] scsi: use the atomic queue limits API in scsi_add_lun
On 3/24/24 16:54, Christoph Hellwig wrote: Switch scsi_add_lun to use the atomic queue limits API to update the max_hw_sectors for devices with quirks. Reviewed-by: Bart Van Assche -- 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/bb3b5924-d266-49f5-944f-5e7ee3d3b5b7%40acm.org.
Re: [PATCH 23/23] block: remove now unused queue limits helpers
On 3/24/24 16:54, Christoph Hellwig wrote: Signed-off-by: Christoph Hellwig Reviewed-by: Bart Van Assche -- 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/d64f697b-7349-4592-814a-00124afb6737%40acm.org.
Re: [PATCH 10/23] scsi: add a device_configure method to the host template
On 3/24/24 16:54, Christoph Hellwig wrote: This is a version of ->slave_configure that also takes a queue_limits structure that the caller applies, and thus allows drivers to reconfigure the queue using the atomic queue limits API. In the long run it should also replace ->slave_configure entirely as there is no need to have two different methods here, and the slave name in addition to being politically charged also has no basis in the SCSI standards or the kernel code. There are two methods with names that are politically charged: slave_configure() and slave_alloc(). Shouldn't both be renamed? * Status: OPTIONAL +* +* Note: slave_configure is the legacy version, use device_configure for +* all new code. */ + int (* device_configure)(struct scsi_device *, struct queue_limits *lim); int (* slave_configure)(struct scsi_device *); The name "device_configure" may make people wonder whether that method perhaps configures a struct device instance. How about using the name "sdev_configure" instead of "device_configure" to make it more clear that this method is used to configure a SCSI device? Thanks, Bart. -- 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/b3ee2dec-3258-4c9f-81d8-0a266128b9ef%40acm.org.
Re: [PATCH 02/23] bsg: pass queue_limits to bsg_setup_queue
On 3/24/24 16:54, Christoph Hellwig wrote: This allows bsg_setup_queue to pass them to blk_mq_alloc_queue and thus set up the limits at queue allocation time. Reviewed-by: Bart Van Assche -- 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/1159bc83-f252-49fe-a15a-e0d0eb18661f%40acm.org.
Re: [PATCH 04/23] scsi: initialize scsi midlayer limits before allocating the queue
On 3/24/24 16:54, Christoph Hellwig wrote: Turn __scsi_init_queue into scsi_init_limits which initializes queue_limits structure that can be passed to blk_mq_alloc_queue. Reviewed-by: Bart Van Assche -- 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/26f51e14-0625-4225-aaf0-f4f7bff5c2ba%40acm.org.
Re: [PATCH 1/2] scsi: core: scsi_device_online() return false if state is SDEV_CANCEL
On 9/22/23 02:36, Wenchao Hao wrote: SDEV_CANCEL is set when removing device and scsi_device_online() should return false if sdev_state is SDEV_CANCEL. IO hang would be caused if return true when state is SDEV_CANCEL with following order: T1: T2:scsi_error_handler __scsi_remove_device() scsi_device_set_state(sdev, SDEV_CANCEL) scsi_eh_flush_done_q() if (scsi_device_online(sdev)) scsi_queue_insert(scmd,...) The command added by scsi_queue_insert() would never be handled any more. Why not? I think the blk_mq_destroy_queue() call in __scsi_remove_device() will cause it to fail. Thanks, Bart. -- 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/50b20a3e-e264-4788-8e52-f7b57cf944f0%40acm.org.
Re: [PATCH 2/2] scsi: scsi_error: Fix device reset is not triggered
On 9/22/23 02:36, Wenchao Hao wrote:
Fix the issue of skipping scsi_try_bus_device_reset() for devices
which is in progress of removing in following order:
T1: T2:scsi_error_handle
__scsi_remove_device
scsi_device_set_state(sdev, SDEV_DEL)
// would skip device with SDEV_DEL state
shost_for_each_device()
scsi_try_bus_device_reset
flush all commands
...
scsi_device is released
Some drivers like smartpqi only implement eh_device_reset_handler,
if device reset is skipped, the commands which had been sent to
firmware or devices hardware are not cleared. The error handle
would flush all these commands in scsi_unjam_host().
When the commands are finished by hardware, use after free issue is
triggered.
Add parameter "check_state" to macro shost_for_each_device() to
determine if check device status when traversal scsi_device
of Scsi_Host, and set this parameter to false when traversal
in scsi_error_handle to address this issue.
The above is incomprehensible to me. Please explain more clearly why
this change is needed.
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index d0911bc28663..db8b9e42267c 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -704,6 +704,23 @@ int scsi_cdl_enable(struct scsi_device *sdev, bool enable)
return 0;
}
+static int __scsi_device_get(struct scsi_device *sdev, bool check_state)
"check_state" is a bad argument name because it does not clearly explain
the purpose of this argument. Would "include_deleted" perhaps be a
better name?
+{
+ if (check_state &&
+ (sdev->sdev_state == SDEV_DEL || sdev->sdev_state == SDEV_CANCEL))
+ goto fail;
+ if (!try_module_get(sdev->host->hostt->module))
+ goto fail;
+ if (!get_device(>sdev_gendev))
+ goto fail_put_module;
+ return 0;
+
+fail_put_module:
+ module_put(sdev->host->hostt->module);
+fail:
+ return -ENXIO;
+}
Looking at the above code, I think we need two functions: one that does
not include the sdev->sdev_state check and a second function that
includes the sdev->sdev_state check (scsi_device_get()) and calls the
first. That will result in code that is easier to read than calls to a
function with a boolean argument.
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index c498a12f7715..e166d053c839 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -389,21 +389,25 @@ extern void __starget_for_each_device(struct scsi_target
*, void *,
/* only exposed to implement shost_for_each_device */
extern struct scsi_device *__scsi_iterate_devices(struct Scsi_Host *,
- struct scsi_device *);
+ struct scsi_device *,
+ bool);
/**
* shost_for_each_device - iterate over all devices of a host
* @sdev: the scsi_device to use as a cursor
* @shost: the scsi_host to iterate over
+ * @check_state: if skip check scsi_device's state to skip some devices
+ * scsi_device with SDEV_DEL or SDEV_CANCEL would be skipped
+ * if this is true
*
* Iterator that returns each device attached to @shost. This loop
* takes a reference on each device and releases it at the end. If
* you break out of the loop, you must call scsi_device_put(sdev).
*/
-#define shost_for_each_device(sdev, shost) \
- for ((sdev) = __scsi_iterate_devices((shost), NULL); \
+#define shost_for_each_device(sdev, shost, check_state) \
+ for ((sdev) = __scsi_iterate_devices((shost), NULL, check_state); \
(sdev); \
-(sdev) = __scsi_iterate_devices((shost), (sdev)))
+(sdev) = __scsi_iterate_devices((shost), (sdev), check_state))
/**
* __shost_for_each_device - iterate over all devices of a host (UNLOCKED)
Since only the SCSI error handler passes 0 as 'check_state' argument to
shost_for_each_device(), instead of adding a boolean argument to that
macro, please do the following:
* Introduce a new macro for the check_state = 1 case.
* Keep the semantics for shost_for_each_device().
With this approach no SCSI LLDs will have to be modified.
Thanks,
Bart.
--
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/ce9cef41-29e2-4056-a60b-b0e4ee1cc17e%40acm.org.
Re: [PATCH 2/2] scsi: Add comment of target_destroy in scsi_host_template
On 9/22/23 02:38, Wenchao Hao wrote:
Add comment to tell callback function target_destroy of
scsi_host_template is called in atomic context.
Signed-off-by: Wenchao Hao
---
include/scsi/scsi_host.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index 49f768d0ff37..a72248fa5adf 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -245,6 +245,9 @@ struct scsi_host_template {
* midlayer calls this point so that the driver may deallocate
* and terminate any references to the target.
*
+* Note: this callback in called with spin_lock held, so donot
+* call functions might cause schedule
+*
This comment should mention which spinlock is held.
Thanks,
Bart.
--
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/9567a78a-baf8-432b-b279-cfc56d370a1d%40acm.org.
Re: Todo list for open-iscsi
On 2020-07-30 21:58, sonu kumar wrote: > I looked into the TODO list of open-iscsi. It is quite old and written > on July 7th,2011. Do we have any updated version of it? > > I am looking for some low hanging tasks to getting started with > open-iscsi and iscsi. It would be really helpful if somebody helps me > to figure it out. How about adding support for MaxOutstandingR2T > 1? See also "Is MaxOutstandingR2T hardcoded?" (https://groups.google.com/forum/#!topic/open-iscsi/d9bUoaYZJiY). Thanks, Bart. -- 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/2fe3c05a-6340-baba-8729-2a24f2ed5a84%40acm.org.
Re: [PATCH v2] iscsi: Report connection state on sysfs
On 3/6/20 11:59 AM, Gabriel Krisman Bertazi wrote:
+static const char *const connection_state_names[] = {
+ [ISCSI_CONN_UP] = "up",
+ [ISCSI_CONN_DOWN] = "down",
+ [ISCSI_CONN_FAILED] = "failed"
+};
+
+static ssize_t show_conn_state(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iscsi_cls_conn *conn = iscsi_dev_to_conn(dev->parent);
+ const char *state = "unknown";
+
+ if (conn->state < ARRAY_SIZE(connection_state_names))
+ state = connection_state_names[conn->state];
+
+ return sprintf(buf, "%s\n", state);
+}
+static ISCSI_CLASS_ATTR(conn, state, S_IRUGO, show_conn_state,
+ NULL);
Thank you for having made this change.
+/* iscsi class connection state */
+enum {
+ ISCSI_CONN_UP = 0,
+ ISCSI_CONN_DOWN,
+ ISCSI_CONN_FAILED,
+};
+
struct iscsi_cls_conn {
struct list_head conn_list; /* item in connlist */
struct list_head conn_list_err; /* item in connlist_err */
@@ -198,6 +205,7 @@ struct iscsi_cls_conn {
struct iscsi_endpoint *ep;
struct device dev; /* sysfs transport/container device */
+ unsigned int state;
};
Can 'state' have another value than those declared in the enumeration
type? If not, how about changing the type of 'state' from 'unsigned int'
into 'enum ...'? If that change is made, a check will have to be added
in show_conn_state() whether conn->state >= 0 since the C standard does
not guarantee whether enumeration types are signed or unsigned.
Bart.
--
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/be183875-967a-402a-7fb4-3d1db3bca0f8%40acm.org.
Re: [PATCH v2] iscsi: Report connection state on sysfs
On 3/5/20 11:20 AM, Gabriel Krisman Bertazi wrote:
Bart Van Assche writes:
On 3/5/20 7:35 AM, Gabriel Krisman Bertazi wrote:
+static const struct {
+ int value;
+ char *name;
+} connection_state_names[] = {
+ {ISCSI_CONN_UP, "up"},
+ {ISCSI_CONN_DOWN, "down"},
+ {ISCSI_CONN_FAILED, "failed"}
+};
+
+static const char *connection_state_name(int state)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(connection_state_names); i++) {
+ if (connection_state_names[i].value == state)
+ return connection_state_names[i].name;
+ }
+ return NULL;
+}
+
+static ssize_t show_conn_state(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iscsi_cls_conn *conn = iscsi_dev_to_conn(dev->parent);
+
+ return sprintf(buf, "%s\n", connection_state_name(conn->state));
+}
+static ISCSI_CLASS_ATTR(conn, state, S_IRUGO, show_conn_state,
+ NULL);
What has been changed in v2 compared to v1? Please always include a
changelog when posting a new version.
Additionally, it seems like the comment I posted on v1 has not been
addressed?
Hi Bart,
v2 no longer has the dependency for specific values for the state, as
you requested. It follows the pattern in similar places in the iscsi
code. Why would designated initializers be better than my solution?
Hi Gabriel,
How about removing the loop as follows?
static const char *const connection_state_names[] = {
[ISCSI_CONN_UP] = "up",
[ISCSI_CONN_DOWN] = "down",
[ISCSI_CONN_FAILED] = "failed",
};
...
if ((unsigned)conn->state < ARRAY_SIZE(connection_state_names))
return sprintf(buf, "%s\n",
connection_state_names[conn->state]);
else
...
...
Thanks,
Bart.
--
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/b2b62579-b2b6-b797-501b-186ac24df399%40acm.org.
Re: [PATCH v2] iscsi: Report connection state on sysfs
On 3/5/20 7:35 AM, Gabriel Krisman Bertazi wrote:
+static const struct {
+ int value;
+ char *name;
+} connection_state_names[] = {
+ {ISCSI_CONN_UP, "up"},
+ {ISCSI_CONN_DOWN, "down"},
+ {ISCSI_CONN_FAILED, "failed"}
+};
+
+static const char *connection_state_name(int state)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(connection_state_names); i++) {
+ if (connection_state_names[i].value == state)
+ return connection_state_names[i].name;
+ }
+ return NULL;
+}
+
+static ssize_t show_conn_state(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iscsi_cls_conn *conn = iscsi_dev_to_conn(dev->parent);
+
+ return sprintf(buf, "%s\n", connection_state_name(conn->state));
+}
+static ISCSI_CLASS_ATTR(conn, state, S_IRUGO, show_conn_state,
+ NULL);
What has been changed in v2 compared to v1? Please always include a
changelog when posting a new version.
Additionally, it seems like the comment I posted on v1 has not been
addressed?
Thanks,
Bart.
--
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/bc70bd6d-6d13-4d1c-8559-140411e361d9%40acm.org.
Re: [PATCH] iscsi: Report connection state on sysfs
On 3/4/20 2:57 PM, Gabriel Krisman Bertazi wrote:
+static const struct {
+ int state;
+ char *name;
+} connection_state_name[] = {
+ {ISCSI_CONN_UP, "up"},
+ {ISCSI_CONN_DOWN, "down"},
+ {ISCSI_CONN_FAILED, "failed"}
+};
+
+static ssize_t
+show_conn_state(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ struct iscsi_cls_conn *conn = iscsi_dev_to_conn(dev->parent);
+
+ return sprintf(buf, "%s\n",
+ connection_state_name[conn->state].name);
+}
+static ISCSI_CLASS_ATTR(conn, state, S_IRUGO, show_conn_state,
+ NULL);
The above code can only work if ISCSI_CONN_UP == 0, ISCSI_CONN_DOWN == 1
and ISCSI_CONN_FAILED == 2. Please don't hardcode such a dependency and
use designated initializers instead.
Thanks,
Bart.
--
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/387eebf7-3256-3462-f91d-e42a5de4824d%40acm.org.
Re: [PATCH 10/24] scsi_transport_srp: switch to SPDX tags
On Wed, 2019-05-01 at 12:14 -0400, Christoph Hellwig wrote: > Use the the GPLv2 SPDX tag instead of verbose boilerplate text. Acked-by: Bart Van Assche -- 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.
Re: [RFC PATCH 1/1] scsi: sd: associate sd_probe_domain with scsi_disk
On 4/4/19 4:04 PM, Ming Lin wrote: async_synchronize_full_domain(_sd_pm_domain); - async_synchronize_full_domain(_sd_probe_domain); + async_synchronize_full_domain(>sd_probe_domain); device_del(>dev); del_gendisk(sdkp->disk); SCSI patches should be prepared against Martin's most recent scsi-queue branch. If you have a look at that branch you will see that scsi_sd_pm_domain and scsi_sd_probe_domain are gone. Bart. -- 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 2/2] libiscsi: Annotate fall-through
This patch avoids that building with W=1 causes the compiler to complain about fall-through. Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com> Cc: Lee Duncan <ldun...@suse.com> Cc: Chris Leech <cle...@redhat.com> --- drivers/scsi/libiscsi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c index b39bfdfec337..345533f80dae 100644 --- a/drivers/scsi/libiscsi.c +++ b/drivers/scsi/libiscsi.c @@ -1705,6 +1705,7 @@ int iscsi_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *sc) sc->result = DID_NO_CONNECT << 16; break; } + /* fall through */ case ISCSI_STATE_IN_RECOVERY: reason = FAILURE_SESSION_IN_RECOVERY; sc->result = DID_IMM_RETRY << 16; -- 2.16.2 -- 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 0/2] libiscsi: Suppress a compiler and a sparse warning
Hello Lee and Chris, The two patches in this series are what I came up with after a review of the gcc and sparse warnings reported against kernel v4.16-rc1. Please consider these patches for kernel v4.17. Thanks, Bart. Bart Van Assche (2): libiscsi: Annotate locking assumptions libiscsi: Annotate fall-through drivers/scsi/libiscsi.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.16.2 -- 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 1/2] libiscsi: Annotate locking assumptions
This patch avoids that sparse reports the following:
drivers/scsi/libiscsi.c:1844:23: warning: context imbalance in
'iscsi_exec_task_mgmt_fn' - unexpected unlock
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Lee Duncan <ldun...@suse.com>
Cc: Chris Leech <cle...@redhat.com>
---
drivers/scsi/libiscsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 15a2fef51e38..b39bfdfec337 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -1832,6 +1832,7 @@ static void iscsi_tmf_timedout(struct timer_list *t)
static int iscsi_exec_task_mgmt_fn(struct iscsi_conn *conn,
struct iscsi_tm *hdr, int age,
int timeout)
+ __must_hold(>frwd_lock)
{
struct iscsi_session *session = conn->session;
struct iscsi_task *task;
--
2.16.2
--
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.
Re: [PATCH] scsi: libiscsi: Allow sd_shutdown on bad transport
On Thu, 2017-12-07 at 19:59 -0200, Rafael David Tinoco wrote: > This happens because iscsi_eh_cmd_timed_out(), the transport layer > timeout helper, would tell the queue timeout function (scsi_times_out) > to reset the request timer over and over, until the session state is > back to logged in state. Unfortunately, during server shutdown, this > might never happen again. Hello Rafael, Have you considered to make iscsi_eh_cmd_timed_out() return BLK_EH_HANDLED if system_state != SYSTEM_RUNNING? That could result in slower shutdown than with your patch but such a change would probably be really easy to review. Thanks, Bart. -- 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.
Re: Any other ways to trigger new LUN discovery?
On 02/15/2017 06:48 AM, Peter Wang wrote: > I am investing new ways to discover LUN exposed by iSCSI targets. > > Currently, most of tools/libs are using user land shell commands > "iscsiadm" to login targets or rescan new LUNs. > sometimes, as I observed, the rescan is time-consuming. in > high-concurrency environment, the overhead by executing massive shell > commands cannot be ignored. > > So, my question is: can we use socket or other efficient ways to trigger > actions that we do with "iscsiadm"? Are you familiar with the "scan" parameter of scsi_mod? See also https://www.spinics.net/lists/linux-scsi/msg95224.html. Bart. -- 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.
Re: Proposal to make automatic target rescans optional
On 02/13/17 07:07, Gorka Eguileor wrote: While working on Cinder, the block storage service in OpenStack, I noticed that the autoscan mechanism in iscsid is creating issues for us and I would like to popose a mechanism to make it optional. The problem for OpenStack deployment comes from the automatic scan of targets at startup, login, and AEN/AER reception. These are clearly great for normal use cases, but in our situation we may have very lively targets that are constantly changing exposed LUNs, and the autoscan mechanism is just polluting our systems with paths that are being removed, because we have multiple systems accessing different LUNs in the same target while they are being removed. More details of the issues can be found in this post [1]. My proposal is adding a new configuration option to the sessions, called "autoscan_en", that allows us to disable the autoscan mechanism. I have submitted the patch via pull request [2], and I don't know if this is an acceptable approach in the eyes of the community, so any guidance will be greatly appreciated. Why to make the iSCSI autoscan mechanism optional? That will make the iSCSI initiator more complicated. Recent kernel versions generate uevents upon reception of a SCSI sense code. How about using that mechanism as a trigger for a rescan for users who want automatic rescanning of LUNs? Bart. Western Digital Corporation (and its subsidiaries) E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of WDC and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -- 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.
Re: [PATCH 0/5] Fix several static checker warnings reported against the iSCSI kernel code
On 03/29/2016 11:26 AM, Mike Christie wrote: On 03/28/2016 03:39 PM, Bart Van Assche wrote: These five patches are what I came up with after analyzing the output of "make M=drivers/scsi W=1 C=2" for the iSCSI kernel code. Please consider these patches for inclusion in kernel v4.7. The actual patches are: 0001-libiscsi-Unexport-iscsi_eh_target_reset.patch 0002-libiscsi-Remove-set-but-not-used-variables.patch 0003-scsi_transport_iscsi-Remove-set-but-not-used-variabl.patch 0004-scsi_transport_iscsi-Unexport-iscsi_is_flashnode_con.patch 0005-scsi_transport_iscsi-Declare-local-symbols-static.patch Thanks Bart. The patches look good to me. Do you want to post them to linux-scsi? I will add my re viewed-by/acked-by tag on the list (or you can just add it when you resend if you want), so Martin or James can pick up into their trees. Hello Mike, Thanks for the review. I will repost these patches on the linux-scsi mailing list with your review tag added because that will save Martin or James the work to process the e-mails with these tags. Bart. -- 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 4/5] scsi_transport_iscsi: Unexport iscsi_is_flashnode_conn_dev()
The output of "git grep -nHw iscsi_is_flashnode_conn_dev" shows
that this function is only called from inside source file
drivers/scsi/scsi_transport_iscsi.c. Hence unexport this function.
Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
---
drivers/scsi/scsi_transport_iscsi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_transport_iscsi.c
b/drivers/scsi/scsi_transport_iscsi.c
index 446781d..dff7413 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -1324,11 +1324,10 @@ EXPORT_SYMBOL_GPL(iscsi_create_flashnode_conn);
* 1 on success
* 0 on failure
*/
-int iscsi_is_flashnode_conn_dev(struct device *dev, void *data)
+static int iscsi_is_flashnode_conn_dev(struct device *dev, void *data)
{
return dev->bus == _flashnode_bus;
}
-EXPORT_SYMBOL_GPL(iscsi_is_flashnode_conn_dev);
static int iscsi_destroy_flashnode_conn(struct iscsi_bus_flash_conn
*fnode_conn)
{
--
2.7.3
--
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 5/5] scsi_transport_iscsi: Declare local symbols static
Avoid that building with W=1 causes gcc to report warnings about
symbols that have not been declared.
Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
---
drivers/scsi/scsi_transport_iscsi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/scsi_transport_iscsi.c
b/drivers/scsi/scsi_transport_iscsi.c
index dff7413..c169fa1 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -1009,7 +1009,7 @@ static void iscsi_flashnode_sess_release(struct device
*dev)
kfree(fnode_sess);
}
-struct device_type iscsi_flashnode_sess_dev_type = {
+static struct device_type iscsi_flashnode_sess_dev_type = {
.name = "iscsi_flashnode_sess_dev_type",
.groups = iscsi_flashnode_sess_attr_groups,
.release = iscsi_flashnode_sess_release,
@@ -1195,13 +1195,13 @@ static void iscsi_flashnode_conn_release(struct device
*dev)
kfree(fnode_conn);
}
-struct device_type iscsi_flashnode_conn_dev_type = {
+static struct device_type iscsi_flashnode_conn_dev_type = {
.name = "iscsi_flashnode_conn_dev_type",
.groups = iscsi_flashnode_conn_attr_groups,
.release = iscsi_flashnode_conn_release,
};
-struct bus_type iscsi_flashnode_bus;
+static struct bus_type iscsi_flashnode_bus;
int iscsi_flashnode_bus_match(struct device *dev,
struct device_driver *drv)
@@ -1212,7 +1212,7 @@ int iscsi_flashnode_bus_match(struct device *dev,
}
EXPORT_SYMBOL_GPL(iscsi_flashnode_bus_match);
-struct bus_type iscsi_flashnode_bus = {
+static struct bus_type iscsi_flashnode_bus = {
.name = "iscsi_flashnode",
.match = _flashnode_bus_match,
};
--
2.7.3
--
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 1/5] libiscsi: Unexport iscsi_eh_target_reset()
Running "git grep -nHw iscsi_eh_target_reset" shows that this
function is only called from inside the drivers/scsi/libiscsi.c
source file. Hence unexport this function.
Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
---
drivers/scsi/libiscsi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 6bffd91..120150a 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -2423,7 +2423,7 @@ static void iscsi_prep_tgt_reset_pdu(struct scsi_cmnd
*sc, struct iscsi_tm *hdr)
*
* This will attempt to send a warm target reset.
*/
-int iscsi_eh_target_reset(struct scsi_cmnd *sc)
+static int iscsi_eh_target_reset(struct scsi_cmnd *sc)
{
struct iscsi_cls_session *cls_session;
struct iscsi_session *session;
@@ -2495,7 +2495,6 @@ done:
mutex_unlock(>eh_mutex);
return rc;
}
-EXPORT_SYMBOL_GPL(iscsi_eh_target_reset);
/**
* iscsi_eh_recover_target - reset target and possibly the session
--
2.7.3
--
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 3/5] scsi_transport_iscsi: Remove set-but-not-used variables
Avoid that building with W=1 causes gcc to report warnings about
set-but-not-used variables.
Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
---
drivers/scsi/scsi_transport_iscsi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/scsi/scsi_transport_iscsi.c
b/drivers/scsi/scsi_transport_iscsi.c
index 4414816..446781d 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2067,13 +2067,10 @@ EXPORT_SYMBOL_GPL(iscsi_alloc_session);
int iscsi_add_session(struct iscsi_cls_session *session, unsigned int
target_id)
{
- struct Scsi_Host *shost = iscsi_session_to_shost(session);
- struct iscsi_cls_host *ihost;
unsigned long flags;
int id = 0;
int err;
- ihost = shost->shost_data;
session->sid = atomic_add_return(1, _session_nr);
if (target_id == ISCSI_MAX_TARGET) {
--
2.7.3
--
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 2/5] libiscsi: Remove set-but-not-used variables
Avoid that building with W=1 causes gcc to report warnings about
set-but-not-used variables.
Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
---
drivers/scsi/libiscsi.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 120150a..c051694 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -2127,7 +2127,7 @@ int iscsi_eh_abort(struct scsi_cmnd *sc)
struct iscsi_conn *conn;
struct iscsi_task *task;
struct iscsi_tm *hdr;
- int rc, age;
+ int age;
cls_session = starget_to_session(scsi_target(sc->device));
session = cls_session->dd_data;
@@ -2188,10 +2188,8 @@ int iscsi_eh_abort(struct scsi_cmnd *sc)
hdr = >tmhdr;
iscsi_prep_abort_task_pdu(task, hdr);
- if (iscsi_exec_task_mgmt_fn(conn, hdr, age, session->abort_timeout)) {
- rc = FAILED;
+ if (iscsi_exec_task_mgmt_fn(conn, hdr, age, session->abort_timeout))
goto failed;
- }
switch (conn->tmf_state) {
case TMF_SUCCESS:
--
2.7.3
--
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.
Re: [PATCH] remove sysfs attr_list
On 02/29/16 17:08, Hannes Reinecke wrote: On 02/29/2016 10:58 PM, Bart Van Assche wrote: On 02/28/16 23:59, Hannes Reinecke wrote: libudev has a _massive_ static memory footprint (Kay doesn't believe in memory allocation). So when using libudev you might end up having a really large memory footprint due to all the on-stack allocations in there. Be especially careful when attempting to use pthreads; debugging stack overflow in pthreads is no fun whatsoever. That's exactly the reason why I never allocate large data structures on the stack in applications I write myself and why I use dynamic memory allocation for large data structures. To make sure that such large stack allocations get detected I set the stack size to a low value: pthread_attr_t attr; pthread_attr_init(); pthread_attr_setstacksize(, PTHREAD_STACK_MIN); pthread_create(..., , ..., ...); Oh, I don't need to detect them. I know exactly where they are. But precisely that is a design goal of the libudev code, so any patches trying to fix that up will be discarded out-of-hand :-( That could be an argument to fork libudev ... Bart. -- 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.
Re: [PATCH] remove sysfs attr_list
On 02/28/16 23:59, Hannes Reinecke wrote: libudev has a _massive_ static memory footprint (Kay doesn't believe in memory allocation). So when using libudev you might end up having a really large memory footprint due to all the on-stack allocations in there. Be especially careful when attempting to use pthreads; debugging stack overflow in pthreads is no fun whatsoever. That's exactly the reason why I never allocate large data structures on the stack in applications I write myself and why I use dynamic memory allocation for large data structures. To make sure that such large stack allocations get detected I set the stack size to a low value: pthread_attr_t attr; pthread_attr_init(); pthread_attr_setstacksize(, PTHREAD_STACK_MIN); pthread_create(..., , ..., ...); Bart. -- 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.
Re: May I do some contributions for iSCSI multiqueue
On 06/25/2015 11:31 PM, LSZhu wrote: I have been working for iSCSI in SUSE for half a year, I have some basic knowledge of iSCSI. I did some debug and performance analyze work before.I am quite interested in iSCSI-mq, I am not a expert here, but may I do some contributions for iSCSI-mq? If you need me in somewhere, please let me know. In my view, there seems such works need to be done: (1) open-iscsi should simulate a multi-queue block device on the initiator side, I mean, /dev/sdc, sdd which simulated by open-iscsi should be multi-queue, just like we want a multi-queue hardware device as a backstore. (2) I/O scheduler is needed in the block layer for multi-queue, for the simulated device mentioned above. (3) open-iscsi should establish more than one connections to the target in a session, and a I/O scheduler is needed here. (4) some performance improve work like how to manage multi-queue threads on multiple CPU cores, how to reduce latency, how to create a better pipeline. I have heard that on the target LIO side, multi-queue work is done. If I am wrong somewhere, please tell me, I would appreciate for that. I know you have did a lot of work for multi-queue, so if you need me somewhere, or I can help in some work, please let me know. Hello Zhu, The most recent discussion about this topic I am aware of can be found at http://thread.gmane.org/gmane.linux.scsi/98199. Please note that I'm not an iSCSI expert. Bart. -- 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 http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: [Lsf] It's time to put together the schedule
On 02/25/15 18:36, Sagi Grimberg wrote: - About shared tags. So for scsi commands and TMFs we don't have a problem since we are guaranteed ITTs are unique. I wander how will we allocate a unique ITT for iscsi specific tasks (LOGIN, TEXT, LOGOUT, NOOP_OUT). My implementation did it per-session, so I reserved a range of ITTs for iscsi specific commands (in a kfifo), I wander how we can do that for multiple sessions. We need some kind of tag allocator for iscsi specific commands. Perhaps Bart/Christoph can advise if a LLD can allocate a unique tag for an LLD specific command using block layer tags. It is possible to allocate a reserved tag from the blk-mq layer by passing true as the fourth argument when calling blk_mq_alloc_request(). However, using that mechanism from inside a SCSI LLD driver would require changes in the SCSI core. The code in scsi_mq_setup_tags() initializes the number of reserved tags to zero. Additionally, the flag use_blk_tags in the SCSI host template makes it easy to use the same code paths in a SCSI LLD in multiqueue and single queue mode. However, the single queue block layer tag allocator does not support reserved tags (see also blk_queue_init_tags()). So it is probably easier to use a custom tag allocator in the iSCSI initiator for iSCSI-specific tasks instead of trying to allocate tags for these tasks from the block layer. Bart. -- 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 http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: [LSF/MM TOPIC] iSCSI MQ adoption via MCS discussion
On 01/09/15 12:39, Sagi Grimberg wrote: On 1/8/2015 4:11 PM, Bart Van Assche wrote: On 01/08/15 14:45, Sagi Grimberg wrote: Actually I started with that approach, but the independent connections under a single session (I-T-Nexus) violates the command ordering requirement. Plus, such a solution is specific to iSER... Which command ordering requirement are you referring to ? The Linux storage stack does not guarantee that block layer or SCSI commands will be processed in the same order as these commands have been submitted. I was referring to the iSCSI session requirement. I initially thought of an approach to maintain multiple iSER connections under a single session but pretty soon I realized that preserving commands ordering this way is not feasible. So independent iSER connections means independent iSCSI sessions (each with a single connection). This is indeed another choice, which we are clearly debating on... I'm just wandering if we are not trying to force-fit this model. How would this model look like? We will need to define another entity to track and maintain the sessions and to allocate the scsi_host. Will that be communicated to user-space? How will error recovery look like? Hello Sagi, As you probably remember scsi-mq support was added in the SRP initiator by changing the 1:1 relationship between scsi_host and RDMA connection into a 1:n relationship. I don't know how much work it would take to implement a similar transformation in the SCSI initiator. Maybe we should wait until Mike's workday starts such that Mike has a chance to comment on this. Bart. PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies). -- 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 http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: [LSF/MM TOPIC] iSCSI MQ adoption via MCS discussion
On 01/08/15 14:45, Sagi Grimberg wrote: Actually I started with that approach, but the independent connections under a single session (I-T-Nexus) violates the command ordering requirement. Plus, such a solution is specific to iSER... Hello Sagi, Which command ordering requirement are you referring to ? The Linux storage stack does not guarantee that block layer or SCSI commands will be processed in the same order as these commands have been submitted. However, it might be interesting to have a look at virtscsi_pick_vq(). I think the purpose of that function is to keep queueing to the same hwq as long as any commands are being executed. This approach avoids that if an application is migrated by the scheduler from one CPU to another that commands get reordered due to have been submitted to different hwq's. I don't think we already have something similar in blk-mq but this is something that could be discussed further. (we might want to leave something for LSF ;)). Agreed :-) Bart. -- 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 http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: [PATCH 7/9] Fix strict-aliasing warning with struct mac_address
On 10/06/14 18:36, Andy Grover wrote:
struct mac_address {
- u8_t addr[6];
+ union {
+ u8_t addr[6];
+ struct {
+ u16_t first_2_bytes;
+ u32_t last_4_bytes;
+ };
+ };
};
This patch changes the size of struct mac_address from 6 into 8. That is
probably unintended ?
Bart.
--
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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Re: iSCSI Conformance Test Tool: iSCT
On 01/04/10 03:46, lancests wrote: We are currently developing iSCT, a tool which does iSCSI conformance test for the target. It's written in Python and can be driven by user- defined test scripts. Using iSCT, it is easy to identify target protocol conformance problems in user space during Open-iSCSI development. iSCT can be found on our website www.storagetest.com. We are proud if iSCT can be of any help to Open-iSCSI. Hello Lance, Are you aware that an open-source iSCSI conformance test tool already exists ? See also Ronnie Sahlberg, SCSI testing/USB devices are amazing, linux-scsi mailing list, April 2013 (http://thread.gmane.org/gmane.linux.scsi/81622/). Bart. -- 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 http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: [PATCH 1/1] Bug fix on IPC address copy
On 11/18/13 22:59, Mike Christie wrote:
On 11/14/2013 05:53 PM, micha...@cs.wisc.edu wrote:
From: Yufei Ren yufei@stonybrook.edu
Got can not connect to iSCSI daemon (111)! error during
starting iscsi service by:
$ iscsiadm -m node --loginall=all
Traced down and found that the sun_path was mis-used in both iscsid
and iscsiadm.
---
usr/iscsid_req.c |2 +-
usr/mgmt_ipc.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/usr/iscsid_req.c b/usr/iscsid_req.c
index 715c0aa..0ebde90 100644
--- a/usr/iscsid_req.c
+++ b/usr/iscsid_req.c
@@ -71,7 +71,7 @@ static int ipc_connect(int *fd, char *unix_sock_name, int
start_iscsid)
memset(addr, 0, sizeof(addr));
addr.sun_family = AF_LOCAL;
-memcpy((char *) addr.sun_path + 1, unix_sock_name,
+memcpy((char *) addr.sun_path + 1, unix_sock_name,
strlen(unix_sock_name));
Hey, since we have some eyes on this patch, one question I have is why
is the + 1 in there for? Is should not be there right?
From the unix(7) man page:
quote
abstract: an abstract socket address is distinguished by the fact
that sun_path[0] is a null byte ('\0'). The socket's address in
this namespace is given by the additional bytes in sun_path that are
covered by the specified length of the address structure. (Null
bytes in the name have no special significance.) The name has no
connection with file system pathnames. When the address of an
abstract socket is returned by getsockname(2), getpeername(2), and
accept(2), the returned addrlen is greater than sizeof(sa_family_t)
(i.e., greater than 2), and the name of the socket is contained in
the first (addrlen - sizeof(sa_family_t)) bytes of sun_path. The
abstract socket namespace is a nonportable Linux extension./quote
Hope this helps,
Bart.
--
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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/groups/opt_out.
Re: kernel oops error
On Sat, Sep 24, 2011 at 9:40 PM, Vivek S vivek...@gmail.com wrote: I am on Dell laptop running Ubuntu 11.04, kernel 2.6.38.11. I'm curious to know who generated kernel 2.6.38.11 ? As far as I know the latest official kernel in the 2.6.38 series is 2.6.38.8 (https://lkml.org/lkml/2011/6/2/417). A quote from the 2.6.38.8 announcement: This is the LAST .38 stable kernel release, please move to the .39-stable tree at this point in time. Bart. -- 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: [PATCH 3/7] iscsid: In foreground mode, treat SIGINT like SIGTERM
On Wed, Jul 20, 2011 at 3:06 PM, Jim Ramsay jim_ram...@dell.com wrote:
This allows ^C to exit iscsid but only when it is running in foreground
mode, which is useful for testing.
Signed-off-by: Jim Ramsay jim_ram...@dell.com
---
usr/iscsid.c | 5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/usr/iscsid.c b/usr/iscsid.c
index 1a37347..9df6658 100644
--- a/usr/iscsid.c
+++ b/usr/iscsid.c
@@ -304,6 +304,11 @@ static void iscsid_shutdown(void)
static void catch_signal(int signo)
{
log_debug(1, pid %d caught signal %d, getpid(), signo);
+
+ /* In foreground mode, treat SIGINT like SIGTERM */
+ if (!daemonize signo == SIGINT)
+ signo = SIGTERM;
+
switch (signo) {
case SIGTERM:
iscsid_shutdown();
The signal handling approach in open-iscsi should be reconsidered.
catch_signal() is a signal handler and hence is not allowed to invoke
fprintf() - which is exactly what iscsid_shutdown() does. See also
IEEE Std 1003.1-2008, paragraph 2.4.3 Signal Actions. In that section
there is a list with functions which are safe to be invoked from a
signal handler. fprintf() is not in that list. The reason that
fprintf() is not in that list is because fprintf() performs locking.
So invoking fprintf() from a signal handler may trigger recursive
locking and hence a deadlock.
Bart.
--
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: [PATCH 0/8] ib/iser: major face lift of the data path code
On Wed, Feb 3, 2010 at 4:30 PM, Or Gerlitz ogerl...@voltaire.com wrote: The following patch set removes some in efficiencies in the iser data path through simplification and reducing the amount of code, using less atomic operations, avoiding TX interrupts, moving to iscsi passthrough mode, etc. I did my best to build it as a sequence of patches and not as one big re-write, to allow for better debugging (e.g bisection) and tuning. Or. [PATCH 01/9] ib/iser: revert commit bba7ebb avoid recv buffer exhaustion [PATCH 02/9] ib/iser: new recv buffer posting logic [PATCH 03/9] ib/iser: remove atomic counter for posted recv buffers [PATCH 04/9] ib/iser: use different CQ for send completions [PATCH 05/9] ib/iser: simplify send flow/descriptors [PATCH 06/9] ib/iser: use atomic allocations [PATCH 07/9] ib/iser: remove unnecessary connection checks [PATCH 08/9] ib/iser: move to use libiscsi passthrough mode [PATCH 09/9] ib/iser: remove redundant locking from iser scsi command response flow Sounds really interesting. Do you have numbers available about how much these patches improve throughput or decrease latency ? Bart. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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: [PATCH 0/8] ib/iser: major face lift of the data path code
On Wed, Feb 3, 2010 at 4:30 PM, Or Gerlitz ogerl...@voltaire.com wrote: The following patch set removes some in efficiencies in the iser data path through simplification and reducing the amount of code, using less atomic operations, avoiding TX interrupts, moving to iscsi passthrough mode, etc. I did my best to build it as a sequence of patches and not as one big re-write, to allow for better debugging (e.g bisection) and tuning. Sounds really interesting. Do you have numbers available about how much these patches improve throughput or decrease latency ? Bart. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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: Over one million IOPS using software iSCSI and 10 Gbit Ethernet
On Mon, Feb 1, 2010 at 10:33 AM, Pasi Kärkkäinen pa...@iki.fi wrote: On Thu, Jan 28, 2010 at 01:44:00PM -0500, Joe Landman wrote: Pasi Kärkkäinen wrote: I suspect that they really aren't seeing ~1us latencies, but that with some neat tricks, it appears to be this. Physically, it isn't there. I'd classify this as a marketing number (e.g. unachievable in applications that matter). I'd be happy to be proven wrong, but there really isn't much to suggest that I am wrong. I hope I get to test some 10 Gbit Ethernet equipment soon.. let's see what I can get myself. If you want to repeat this test, please keep in mind that this test is CPU or memory-bound, not I/O-bound. Letting the block layer combine 512-byte blocks into larger blocks stresses the CPU and memory system. As an example, the command below reported between 200.000 and 400.000 IOPS, depending on the performance of the underlying hardware of the system the command was run on: fio --bs=512 --size=1G --buffered=1 --ioengine=sync --numjobs=1 --group_reporting --name=dev-null /dev/null Bart. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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: Over one million IOPS using software iSCSI and 10 Gbit Ethernet
On Thu, Jan 28, 2010 at 1:36 PM, Pasi Kärkkäinen pa...@iki.fi wrote: Please check these news items: http://blog.fosketts.net/2010/01/14/microsoft-intel-push-million-iscsi-iops/ http://communities.intel.com/community/openportit/server/blog/2010/01/19/100-iops-with-iscsi--thats-not-a-typo http://www.infostor.com/index/blogs_new/dave_simpson_storage/blogs/infostor/dave_simpon_storage/post987_37501094375591341.html 1,030,000 IOPS over a single 10 Gb Ethernet link Specifically, Intel and Microsoft clocked 1,030,000 IOPS (with 512-byte blocks), and more than 2,250MBps with large block sizes (16KB to 256KB) using the Iometer benchmark So.. who wants to beat that using Linux + open-iscsi? :) A few comments: * A throughput of 2250 MB/s over a 10 Gb/s link is only possible when running read and write tests simultaneously and when counting the traffic that flows in both directions. * These results say more about the NIC used than about they say about the iSCSI initiator software used. A quote from http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-USEventID=1032432957CountryCode=US: Topics we discuss include [ ... ] Advanced iSCSI acceleration features in Intel Ethernet Server Adapters and how they work with the native iSCSI support in Windows Sever 2008 R2. Bart. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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: Over one million IOPS using software iSCSI and 10 Gbit Ethernet
On Thu, Jan 28, 2010 at 4:01 PM, Joe Landman land...@scalableinformatics.com wrote: Pasi Kärkkäinen wrote: Please check these news items: http://blog.fosketts.net/2010/01/14/microsoft-intel-push-million-iscsi-iops/ http://communities.intel.com/community/openportit/server/blog/2010/01/19/100-iops-with-iscsi--thats-not-a-typo http://www.infostor.com/index/blogs_new/dave_simpson_storage/blogs/infostor/dave_simpon_storage/post987_37501094375591341.html 1,030,000 IOPS over a single 10 Gb Ethernet link This is less than 1us per IOP. Interesting. Their hardware may not actually support this. 10GbE typically is 7-10us, though ConnectX and some others get down to 2ish. Which I/O depth has been used in the test ? Latency matters most with an I/O depth of one and is almost irrelevant for high I/O depth values. Bart. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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: [Scst-devel] iSCSI latency issue
On Wed, Nov 25, 2009 at 5:57 PM, Shachar f shacharf...@gmail.com wrote: I'm running open-iscsi with scst on Broadcom 10Gig network and facing write latency issues. When using netperf over an idle network the latency for a single block round trip transfer is 30 usec and with open-iscsi it is 90-100 usec. I see that Nagle (TCP_NODELAY) is disabled when openning socket on the initiator side and I'm not sure about the target side. Vlad, Can you elaborate on this? Are others in the mailing list aware to possible environment changes that effext latency? more info - I'm running this test with Centos5.3 machines with almost latest open-iscsi. Please make sure that interrupt coalescing has been disabled -- see also ethtool -c. Bart. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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: iSCSIUTIL - frontend (in QT for KDE) for iSCST-Target and Open-iSCSI
2009/7/24 Mike Christie micha...@cs.wisc.edu On 07/22/2009 02:56 PM, Artur Piechocki wrote: Hello Some time ago I wrote small frontend for iSCSI-Target and Open-iSCSI for KDE3x and QT3. Is the goal to get this merged in KDE? Does KDE have any programs for managing this stuff? What about GNOME? Regarding the last question: it is possible to run KDE programs on a GNOME desktop and to run GNOME programs on a KDE desktop. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iSCSI initiator implementation question
On Thu, Jun 18, 2009 at 12:12 PM, Hannes Reineckeh...@suse.de wrote: Joachim Worringen wrote: On Jun 18, 11:19 am, Boaz Harrosh bharr...@panasas.com wrote: On 06/18/2009 10:56 AM, Joachim Worringen wrote: Is there a specific reason for this? iSCSI would surely benefit from using high-performance, non-tcp sockets if available (I'm talking about SuperSockets in this case, see http://www.dolphinics.com/products/dolphin-supersockets.html). Sure sounds nice. If it is a simple and compatible change it sounds very good. [ ... ] Well, the obvious solution here is to implement another transport module (eg iscsi_supersockets.c) much like it's done for iSER. The rest of the code should be sufficiently abstracted to handle it properly. There is a reason why it's called iscsi_tcp.c ... Another alternative is to implement the necessary support in the Linux kernel such that the existing iSER, IBoIP, SRP and SDP kernel code can be reused with the Dolphin hardware. It's not yet clear to me whether SuperSockets have any advantages over SDP. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iSCSI initiator implementation question
On Thu, Jun 18, 2009 at 1:14 PM, FUJITA Tomonorifujita.tomon...@lab.ntt.co.jp wrote: On Thu, 18 Jun 2009 03:53:47 -0700 (PDT) Joachim Worringen worrin...@googlemail.com wrote: On Jun 18, 12:37 pm, FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote: Well, anyway seems that 10GbE is slowly killing all niche high performance interconnect technology. Of course Ethernet always wins conc. market share. But 10GigE doesn't help you if you need really low latency; it does hardly give you an advantage over 1GigE in this respect. Seems that the latency diffence with 10GbE is smaller than one with 1GbE. There were lots of niche high performance interconnect companies in 1GbE era but now there are not many. Yes, the latency diffence still matters for some people but the market is getting smaller. Numbers please. From the last numbers I have seen the latency difference between 10 GbE and fast non-Ethernet networks is still significant. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iSCSI initiator implementation question
On Thu, Jun 18, 2009 at 2:14 PM, FUJITA Tomonorifujita.tomon...@lab.ntt.co.jp wrote: On Thu, 18 Jun 2009 13:33:42 +0200 Bart Van Assche bart.vanass...@gmail.com wrote: Numbers please. From the last numbers I have seen the latency difference between 10 GbE and fast non-Ethernet networks is still significant. http://74.125.153.132/search?q=cache:lWqSaJ-iJ50J:www.chelsio.com/poster.html%3FsearchText%3Dcybermedia+latency+chelsio+osaka+10.49+microsecondscd=2hl=jact=clnkgl=jp I think that 10GbE vendors are happy to give you lots of results. Maybe it's still significant for you but it's not for some, which I had worked with. Thanks for the reference. The cited publication mentions a latency of 10.49 µs for an advanced 10 GbE interface. This is relatively high compared to the latency of e.g. InfiniBand (between 2 and 3 µs). Whether or not this difference matters depends on the workload. As known for filesystem I/O the block sizes between 4 KB and 64 KB dominate. These block sizes correspond to a transfer time of 3 µs and 49 µs respectively at a rate of 10 Gb/s. So for a workload that consists mainly of 4 KB blocks, the latency difference is important but for a workload that consists mainly of 64 KB blocks, the latency difference is not that important. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: RFC: do we need a new list for kernel patches
On Sun, Jun 14, 2009 at 11:23 AM, Boaz Harroshbharr...@panasas.com wrote: On 06/11/2009 08:41 PM, Mike Christie wrote: It seems like we have a lot of members on the list that are not kernel developers, but we now have 5 iscsi drivers (qla4xxx, bnx2i, cxgb3i, iscsi_tcp and ib_iser) with another being written. So it seems like we are going to have lots of patches. I would also like to start sending my kernel patches out in a way that everyone can see them. Previously to avoid noise on this list, I have been pinging you guys privately which just does not work so well now when we have so many people. What do you people think? Do other people on the list prefer to see everything here, so you can see what features are making progress? I vote: One list, All patches posted I agree that having just one mailing list is the most convenient for kernel developers. But not everyone who is subscribed to open-iscsi is a kernel developer. Wouldn't it be more convenient for iSCSI users to have two lists -- one intended for iSCSI users, and one for iSCSI developers, such that the users can subscribe to the former only ? Just my two cents. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Building a multipath setup with DRBD in dual-Primary
On Fri, May 29, 2009 at 5:21 PM, Wido wid...@gmail.com wrote: Last night i had the idea of building a multipath iSCSI setup with DRBD in Primary/Primary. [ ... ] Is my setup a possibility or should i stay with the old regular setup of a Primary/Standy with heartbeat? I strongly recommend you to use a primary/standby setup + heartbeat when using dm-multipath instead of a primary/primary setup. With the latter setup you risk to run into data corruption. See also http://lkml.org/lkml/2009/4/13/80. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iSCSI and FileSystem (ext2/ext3)
On Wed, Apr 15, 2009 at 8:24 PM, benoit plessis plessis.ben...@gmail.com wrote: I wanted to share some infos about a discovery we made using mysql over iSCSI. A few questions: - Was MySQL configured for direct I/O or for buffered I/O ? - Which mount options were used with the ext2 / ext3 filesystems ? Was noatime or relatime enabled ? Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iSCSI and FileSystem (ext2/ext3)
On Wed, Apr 15, 2009 at 9:19 PM, Pasi Kärkkäinen pa...@iki.fi wrote: noop is usually good for the initiator. cfq has a feature (or a bug?) that prevents achieving queue depths deeper than 1, and thus limits your bandwidth a lot when there are (or should be) many ios on the fly at the same time. Hello Pasi, Do you have any idea whether modifying the tunable CFQ parameters could resolve the bandwidth limiting behavior of CFQ ? $ ls /sys/block/sda/queue/iosched back_seek_max fifo_expire_async quantum slice_async_rq slice_sync back_seek_penalty fifo_expire_sync slice_async slice_idle Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iSCSI and FileSystem (ext2/ext3)
On Wed, Apr 15, 2009 at 9:19 PM, Pasi Kärkkäinen pa...@iki.fi wrote: noop is usually good for the initiator. cfq has a feature (or a bug?) that prevents achieving queue depths deeper than 1, and thus limits your bandwidth a lot when there are (or should be) many ios on the fly at the same time. Do you remember on which kernel version you observed the above behavior ? This might be a bug in the CFQ scheduler. I found the following in the 2.6.28 changelog: cfq-iosched: fix queue depth detection. See also http://www.eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.28 or http://lkml.org/lkml/2008/8/22/39. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iSCSI and FileSystem (ext2/ext3)
On Thu, Apr 16, 2009 at 1:10 PM, Ulrich Windl ulrich.wi...@rz.uni-regensburg.de wrote: Considering that most remote iSCSI targets have intelligece of their own, the use of a no-op i/O scheduler seems justified. I think multiple I/O schedulers on both ends don't necessarily make things faster, unless there is a bunch of requests that can be compacted into one. Then throughput rises while response may decline. Is request merging implemented in the SCSI layer or in the I/O scheduler ? Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iSCSI and FileSystem (ext2/ext3)
On Thu, Apr 16, 2009 at 2:07 PM, Pasi Kärkkäinen pa...@iki.fi wrote: Iirc it has been with RHEL5/CentOS5 2.6.18 based kernels.. Mike Christie has been writing about this aswell.. dunno about what kernels he has seen it with. Then again CFQ was designed for single disk workstations.. I have seen the above statement about CFQ only once in the past, and that was in this post: http://www.mail-archive.com/cen...@centos.org/msg04648.html. But if CFQ really was designed for single disk workstations, I do not understand why it has been chosen as the default in Red Hat Enterprise Linux 4. There must have been a good reason behind that choice. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Multipath + iscsi + SLES10 SP2 / REDHAT 5.3 / Oracle Linux 5 update 3
On Mon, Apr 13, 2009 at 10:33 PM, Mike Christie micha...@cs.wisc.edu wrote: I think linux is just not so good with smaller IO sizes like 4K. I do not see good performance with Fibre Channel or iscsi. Most people run a filesystem on top of a block device imported via open-iscsi. It is well known that a filesystem performs I/O to the underlying block device using block sizes between 4 KB and 64 KB, with a significant fraction being 4 KB I/O's. If there was a performance problem in Linux with regard to small block sizes, filesystem performance in Linux would suffer. I have not yet seen statistics that show that Linux' filesystem performance is worse than for other operating systems. But I have already seen measurements that show the contrary. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iSCSI and FileSystem (ext2/ext3)
On Wed, Apr 15, 2009 at 8:24 PM, benoit plessis plessis.ben...@gmail.com wrote: I wanted to share some infos about a discovery we made using mysql over iSCSI. We have a bunch of replicated mysql server, initially all using ext3, due to perfs problems we tried comparing persf in ext3 vs ext2, and we found the following: server using ext3 normal iops 100 normal bw 25/30Mbps peak iops 1000 peak bw 45/52Mbps server using ext2 normal iops 40 normal bw 4/5 Mbps peak iops 50 peak bw 7/8 Mbps All servers using the noop scheduler. The ext3 FS wasn't even using journalised datas, only the standard metadata configuration, but the impact on resource usage is quite impressive So the question is, what do you use as FS over iSCSI ? Why are you using the noop scheduler on the initiator instead of deadline or CFQ ? The performance difference you observed is probably caused by something else than the filesystem. When running bonnie++ on a local filesystem, xfs gives better performance than ext2, and ext2 gives better performance than ext3. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Multipath + iscsi + SLES10 SP2 / REDHAT 5.3 / Oracle Linux 5 update 3
On Mon, Apr 13, 2009 at 10:33 PM, Mike Christie micha...@cs.wisc.edu wrote: I think linux is just not so good with smaller IO sizes like 4K. I do not see good performance with Fibre Channel or iscsi. Can you elaborate on the above ? I have already measured a throughput of more than 60 MB/s when using the SRP protocol over an InfiniBand network with a block size of 4 KB blocks, which is definitely not bad. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Tuning iSCSI between Linux and NetAPP
On Tue, Apr 14, 2009 at 7:09 PM, Dmitry Yusupov dmitry_...@yahoo.com wrote: NexentaStor also is very good candidate for CIFS workgroups/AD environments with the whole SMB stack implemented in the kernel, which boosts performance over the top. And as far as iSCSI target - I would recommend to use COMSTAR, which is ZFS integrated in Nexenta [2]. Do you have any performance numbers available for the combination of open-iscsi and the NexentaStor target ? Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Low IOPs for certain block sizes
Hello, While running iSCSI performance tests I noticed that the performance for certain block sizes deviated significantly (more than ten times) from the performance for other block sizes, both larger and smaller. This surprised me. The test I ran was as follows: * A file of 1 GB residing on a tmpfs filesystem was exported via iSCSI target software. The test has been repeated with both SCST and STGT. * On the initiator system open-iscsi version 2.0.870 was used for performing reads and writes with dd via direct I/O. Read-ahead was set to zero. * Both systems were running kernel 2.6.29.1 in run level 3 (no X server) and the 1 GbE interfaces in the two systems were connected via a crossed cable. The MTU has been left to its default value, 1500 bytes. Netperf reported a throughput of 600 Mbit/s = 75 MB/s for the TCP/IP stream test on this setup. * 128 MB of data has been transferred during each test. * Each measurement has been repeated three times. * All caches were flushed before each test. * The ratio of standard deviation to average was 2% or lower for all measurements. * The measurement result are as follows (transfer speeds in MB/s): Block SCST STGT SCST STGT size writing writing reading reading -- --- --- --- --- 64 MB 71.7 63.3 62.1 58.4 32 MB 71.9 63.4 61.7 58.1 16 MB 72.4 63.0 61.7 57.1 8 MB 72.7 63.3 61.7 56.9 4 MB 72.9 63.5 61.3 57.0 2 MB 72.8 59.5 60.3 56.9 1 MB 72.1 38.7 59.4 56.0 512 KB 67.3 21.4 58.0 54.4 256 KB 67.4 22.8 55.5 53.4 128 KB 60.9 22.6 53.3 51.7 64 KB 53.2 22.2 53.0 45.7 32 KB 48.9 21.6 40.0 40.0 16 KB 40.0 20.8 0.6 1.3 8 KB 20.0 19.9 19.9 20.0 4 KB 0.6 1.6 18.9 10.3 All results look normal to me, except the write throughput for a block size of 4 KB and the read throughput for a block size of 16 KB. Regarding CPU load: during the 4 KB write test, the CPU load was 0.9 on the initiator system and 0.1 on the target. Has anyone observed similar behavior before ? Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: PATCH: fix iBFT firmware reading with newer kernels
On Thu, Jan 29, 2009 at 12:34 AM, Mike Christie micha...@cs.wisc.edu wrote: strncat(dev_dir, /, FILENAMESZ); strncat(dev_dir, dent-d_name, FILENAMESZ); I assume the third argument should have been FILENAMESZ - strlen(dev_dir) ? Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: PATCH: make open-iscsi userspace tools functionality available as a library
On Tue, Jan 20, 2009 at 7:20 PM, Konrad Rzeszutek kon...@virtualiron.com wrote: I would recommend that you provide as the first variable in all of the structs an unsigned int called 'version'. This way if the structs are extended they would be backwards compatible and there is an easy way to identify which version of structs they are. Erm, given the amount of programs which will probably end up using this (not all that much) a distro should be able to easily rebuild all those in case of an ABI change and thus a soname bump. I understand what you are trying to say here, but IMHO the added complexity and ugliness is not worth it. I disagree. The ABI in a distro is a holy thing. When a Linux distro releases their libraries (look for example at libvirt), they can't modify it for the next 7 years (sure they can do it underneath the covers, but look at the Red Hat kernel with those #ifdef __GENKSYSM__ to work-around this). I am curious to understand what is complex and ugly about it? Could you be more specific please. I agree that having a stable binary interface is very important for a shared library. But if glibc doesn't have versioned structs, why would these be needed in an iscsi library ? Please keep in mind that it is possible to define a new version of a shared library in case the ABI changes. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: PATCH: make open-iscsi userspace tools functionality available as a library
On Mon, Jan 19, 2009 at 2:07 PM, Hans de Goede hdego...@redhat.com wrote: Therefore we would like to export (some) of the functionality of iscsiadm as a C-library. Great ! I've got documentation of the proposed API here: http://people.atrpms.net/~hdegoede/html/libiscsi_8h.html Not so great: libiscsi_get_error_string() This function can be called to get a human readable error string when a libiscsi function has returned an error. This function uses a static buffer thus the result is only valid as long as no other libiscsi calls are made after the failing function call. This makes it impossible to use libiscsi_get_error_string() in a safe way in multithreaded software. Furthermore, there are some minor spelling issues, e.g. cleanups. Shouldn't this be cleans up ? Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: PATCH: make open-iscsi userspace tools functionality available as a library
On Mon, Jan 19, 2009 at 4:35 PM, Hans de Goede hdego...@redhat.com wrote: - libiscsi_discover_sendtargets - maybe (very maybe) the int port could be dropped and const char *address could be of the form address_or_host[:port]. Regarding defaults and all that. Nah, that is ok for a cmdline interface, but cumbersome for an API, we could do something where port == 0 would choose the default port though. Have you considered to replace both const char *address and int port by const struct sockaddr *address, socklen_t address_len ? This would avoid having to figure out inside libiscsi_discover_sendtargets() whether the passed address is in IPv4 or in IPv6 format (if numeric). Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Bad TCP Checksums Over Loopback
On Mon, Jan 12, 2009 at 11:48 AM, avis...@gmail.com wrote: Here are some statistics from wireshark: Bad checksum(TCP): 35,963 Usually this means that Wireshark was unable to capture all packets, not that there was a problem with the packets themselves. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Iozone Performance Oddities
On Tue, Jan 13, 2009 at 8:31 PM, Norm normel...@gmail.com wrote: I've run iozone over a new iscsi mount that we're configuring. The client is RedHat 5, the server is Solaris on a Sun X4500 (thumper) with the ZFS filesystem. On the client side, things are formatted with the ext3 filesystem running on an LVM partition. I've posted by iozone results: http://wnelto.people.wm.edu/iozone.htm It appears that, for most tests, there is a large performance penalty when the file size hits 4 or 8 GB. I suspect I'm missing something obvious here. Any ideas? How much RAM is present in the ZFS server ? Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Iozone Performance Oddities
On Tue, Jan 13, 2009 at 8:50 PM, Norm normel...@gmail.com wrote: How much RAM is present in the ZFS server ? The ZFS server has 16GB. The client has 2GB (I'm not sure how iSCSI caching works, if any). Apparently iozone has been run with the following command line options: iozone -Raz -b /tmp/iozone.wks -g 8g This means that you have been measuring how well Linux can cache reads and writes to block devices instead of the iSCSI performance. The iozone options -o and/or -+r might help to bypass Linux' block device cache. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: connection, host resets, I/O errors eventually (DRBD, but not only)
On Thu, Jan 8, 2009 at 12:44 PM, Tomasz Chmielewski man...@wpkg.org wrote:
Anyone using iSCSI over DRBD? And a slow internet link perhaps?
How reliable is the link you are using -- which percentage of packets
is lost ? You can test this e.g. with the ping command. The following
command will generate about 32 KB/s of network traffic and reports the
percentage of lost packets:
# ping -q -i 0.01 -c1000 -s160 ${remote_ip}
PING 192.168.1.102 (192.168.1.102) 160(188) bytes of data.
--- 192.168.1.102 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 8997ms
rtt min/avg/max/mdev = 0.000/0.048/0.474/0.027 ms
Bart.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: connection, host resets, I/O errors eventually (DRBD, but not only)
On Fri, Jan 9, 2009 at 3:22 PM, Tomasz Chmielewski man...@wpkg.org wrote:
Bart Van Assche schrieb:
# ping -q -i 0.01 -c1000 -s160 ${remote_ip}
I get about 1% losses.
IMHO running iSCSI over a slow link should work, but a packet loss of
1% is troublesome. On a local network the packet loss rate is about
0.001% (1e-5) for 1000-byte packets.
Bart.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Software raid over iSCSI
On Tue, Dec 23, 2008 at 9:13 AM, Andrew McGill list2...@lunch.za.net wrote: From another list, the mail below is a proposal to change the default partition table for disks from 512 bytes to 4096 bytes. I think that once implemented (in a few years / days time), it will make some of the alignment problems due to the 512-byte MSDOS partition table go away. The complete thread has some references to how the SCSI code determines the geometry -- http://news.gmane.org/group/gmane.linux.utilities.util-linux-ng/last= Thanks for the link. This thread contains an interesting suggestion, namely choosing 255/56/X for C/H/S. This C/H/S choice guarantees that partitions are aligned at 4096 byte boundaries. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iSCSI overhead
On Tue, Dec 23, 2008 at 3:00 PM, r...@megabit.net wrote: Hmmm maybe you misunderstood me - a performance improvement would be nice but that was not the point of my mail: I'm just wondering why there seems to be such a big overhead on the network while doing synchronus reads and writes to the iSCSI device. It's possible that I misunderstood you. I should also have made more clear what I had in mind, namely that the readahead settings on the initiator system have a significant impact on random I/O performance. But apparently you were running a sequential I/O test ? Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Software raid over iSCSI
On Mon, Dec 22, 2008 at 1:18 PM, Ulrich Windl ulrich.wi...@rz.uni-regensburg.de wrote: I think since ZBR (Zone Bit Recording) the number of sectors per cylinder is variable. thus it makes no sense for any higher-level disk software to try to deal with heads or cylinders. Since ATA (about 1990) only the controller on the disk knows the tracks, heads, and cylinders. The rest is just logic. Therefore SCSI (nad now LBA) just uses logical block numbers. At least with IET, changing the heads/sector values for the exported disk does improve speed. See also http://www.mail-archive.com/open-iscsi@googlegroups.com/msg01664.html. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Software raid over iSCSI
On Mon, Dec 22, 2008 at 2:17 PM, Eric ericvanblokl...@gmail.com wrote: Thanks for definitive answer and the link to a great thread. I need one more: I have to set the heads and cylinders on the disk partitions of the virtualized servers. Now I assume I also have to set heads and cylinders on the raid partions, exported by the targets. Is this assumption correct? I'm not 100% sure, but the CHS layout of the disk itself (not the partitions) might be the layout you have to tune. If I remember correctly, IET performance is suboptimal if partition boundaries are not aligned with page boundaries. Or: partition boundaries should be a multiple of 4096 KB. Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Correct way to change I/O scheduler in a iSCSI dev
On Tue, Nov 25, 2008 at 3:07 PM, Santi Saez [EMAIL PROTECTED] wrote: What's the correct way to change configuration parameters for an iSCSI device? For example I/O scheduler, max_sectors_kb, etc... Please have a look at the hierarchy created by udevd in /dev. You can find there soft links that have a name that does not change over sessions and that point to the devices created by the iSCSI initiator (/dev/sdb etc). Bart. --~--~-~--~~~---~--~~ 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: Extremely slow read performance, but write speeds are near-perfect!
On Fri, Nov 21, 2008 at 9:16 PM, Heady [EMAIL PROTECTED] wrote: * The target is IET running on a Xen dom0 running Gentoo Linux with [ ... ] Maybe not the advice you are looking for, but did you already have a look at the SCST iSCSI target implementation ? It's faster than IET and better maintained. There is also a section about how to tune read-ahead settings in the file scst/README. See also http://scst.sourceforge.net/ for more information. Bart. --~--~-~--~~~---~--~~ 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: Extremely slow read performance, but write speeds are near-perfect!
On Sat, Nov 22, 2008 at 10:58 AM, Tracy Reed [EMAIL PROTECTED] wrote: On Sat, Nov 22, 2008 at 09:44:09AM +0100, Bart Van Assche spake thusly: Maybe not the advice you are looking for, but did you already have a look at the SCST iSCSI target implementation ? It's faster than IET and better maintained. There is also a section about how to tune Does it do MC/S or Error Recovery Level 2 or 3? Not that I know of. Would you like to see these features implemented in SCST ? (CC'd Vladislav Bolkhovitin, SCST maintainer) Bart. --~--~-~--~~~---~--~~ 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: An note on the HP MPX 100
On Wed, Nov 19, 2008 at 11:03 AM, Ulrich Windl [EMAIL PROTECTED] wrote: maybe some of you like to know what I think to have found out: The HP EVA iSCSI connectivity MPX 100 box seems to be an OEM version of the Qlogic iSR6140 Universal SAN Connectivity (with different firmware however). Does this box have an Ethernet network interface ? If so, any idea whether this is a regular Ethernet network interface or a QLogic iSCSI HBA ? Looking at the first three bytes of the MAC address might reveal this (not sure about this). Bart. --~--~-~--~~~---~--~~ 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: A note on the HP MPX 100
On Thu, Nov 20, 2008 at 8:33 AM, Ulrich Windl [EMAIL PROTECTED] wrote: I assume there are quite a few iSCSI boxes without Ethernet interfaces ;-) iSCSI does not only run over Ethernet but also over e.g. InfiniBand. The box has two Gb Ethernet interfaces that, AFAIK, have hardware acceleration for iSCSI. (If you search the Internet for Qlogic iSR6140 Universal SAN Connectivity you may find the whitepaper that shows an image of the connectors of the box) The access to the hardware is resticted, but having the facts that qlogic built the hardware for iSCSI, it's quite possible that they use their own hardware- accelerated iSCSI HBAs. Will the MAC 00:C0:DD:0D:0C:8B uncover the secret? From http://standards.ieee.org/regauth/oui/index.shtml: 00-C0-DD (hex)QLogic Corporation 00C0DD (base 16)QLogic Corporation 6321 Bury Dr. Eden Prarie MN 55346 UNITED STATES The above information is consistent with what you reported, namely that the NIC's have hardware iSCSI acceleration. This information is relevant because it tells us something about where to look for the CHAP implementation. Maybe one of the people who reads this mailing list knows whether CHAP support for QLogic HBA's is implemented in the QLogic kernel driver or the QLogic HBA BIOS ? Bart. --~--~-~--~~~---~--~~ 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: test/regression.sh: ext3 filesystem creation fails
On Fri, May 23, 2008 at 8:09 PM, Mike Christie [EMAIL PROTECTED] wrote: I have seen this a couple times in past versions too. If you run mkfs by hand is it fine? I get the same error when I run mkfs.ext3 -F directly. Is this an initiator or a target issue ? Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
iSCSI initiator lockup
Hello,
Due to resetting an iSCSI target (SCST) while an iSCSI session was
active, the iSCSI initiator seems to be locked up. E.g. when I try to
run the command iscsiadm -m session or iscsiadm ... --logout,
these command hangs forever. This is probably not the intended
behavior ?
# cat /etc/issue
Ubuntu 7.10 \n \l
# uname -a
Linux INF010 2.6.24 #1 SMP Thu Feb 7 15:45:15 CET 2008 x86_64 GNU/Linux
# dpkg -l open-iscsi
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name VersionDescription
+++-==-==-
ii open-iscsi 2.0.865-1 High performance, transport independent iSCS
# pidof iscsid
4787 4786
# strace iscsiadm -m session
socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, [EMAIL PROTECTED], 110) = 0
write(3, \10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
4760) = 4760
recvfrom(3, unfinished ...
# strace iscsiadm -m node -p 192.168.64.13 -T ... --logout
socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, [EMAIL PROTECTED], 110) = 0
write(3, \10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
4760) = 4760
recvfrom(3, unfinished ...
Kernel messages:
May 7 11:34:20 INF010 kernel: [0.00] scsi28 : iSCSI Initiator
over TCP/IP
May 7 11:34:20 INF010 kernel: [0.00] scsi 28:0:0:0:
Direct-Access SCST_FIO vdisk0096 PQ: 0 ANSI: 4
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Very
big device. Trying to use READ CAPACITY(16).
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde]
6778558976 512-byte hardware sectors (3470622 MB)
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Write
Protect is off
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Mode
Sense: 6b 00 10 08
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Write
cache: enabled, read cache: enabled, supports DPO and FUA
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Very
big device. Trying to use READ CAPACITY(16).
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde]
6778558976 512-byte hardware sectors (3470622 MB)
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Write
Protect is off
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Mode
Sense: 6b 00 10 08
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Write
cache: enabled, read cache: enabled, supports DPO and FUA
May 7 11:34:20 INF010 kernel: [0.00] sde: unknown partition table
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde]
Attached SCSI disk
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: Attached
scsi generic sg5 type 0
May 7 11:34:20 INF010 kernel: [0.00] scsi 28:0:0:1:
Direct-Access SCST_FIO vdisk1096 PQ: 0 ANSI: 4
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Very
big device. Trying to use READ CAPACITY(16).
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf]
6778558976 512-byte hardware sectors (3470622 MB)
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Write
Protect is off
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Mode
Sense: 6b 00 10 08
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Write
cache: enabled, read cache: enabled, supports DPO and FUA
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Very
big device. Trying to use READ CAPACITY(16).
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf]
6778558976 512-byte hardware sectors (3470622 MB)
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Write
Protect is off
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Mode
Sense: 6b 00 10 08
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Write
cache: enabled, read cache: enabled, supports DPO and FUA
May 7 11:34:20 INF010 kernel: [0.00] sdf: unknown partition table
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf]
Attached SCSI disk
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: Attached
scsi generic sg6 type 0
May 7 11:34:27 INF010 kernel: [0.00] sd 28:0:0:0: [sde]
Synchronizing SCSI cache
May 7 11:34:27 INF010 kernel: [0.00] iscsi: cmd 0x35 is not queued (6)
May 7 11:34:27 INF010 last message repeated 2 times
May 7 11:34:27 INF010 kernel: [0.00] sd 28:0:0:0: [sde]
Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
May 7 11:34:27 INF010 kernel: [0.00] sd 28:0:0:1: [sdf]
Synchronizing SCSI cache
May 7 11:34:27 INF010 kernel: [0.00] iscsi: cmd 0x35 is not queued (6)
May 7 11:34:27 INF010 last message repeated 2 times
May 7 11:34:27 INF010 kernel: [0.00] sd 28:0:0:1: [sdf]
iSCSI target compliance testing
Hello, Does anyone on this list have experience with iSCSI target compliance testing ? I found some old references to a compliance test by University of New Hampshire Interoperability Labs (UNH-IOL) but have been unable so far to find the source code of these tests. See also: * November 4, 2004: http://www.byteandswitch.com/document.asp?doc_id=62308 * May 1, 2004: http://www.thefreelibrary.com/iSCSI+deployment+in+business+IP+storage+network-a0118903279 * November 26, 2001: http://safari.peachpit.com/0201752778/ch14lev1sec2 Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
iscsiadm: buffer size 32768 too small for data length 32768
Hello, Has anyone here experience with letting the open-iscsi initiator connect to an iSCSI target system on which many (hundreds) of target have been configured ? From a certain number of targets on the open-iscsi initiator starts complaining that the buffer size is too small. Can I increase the 32768 byte buffer limit without recompiling open-iscsi ? Thanks, Bart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
