Q: - PDU header Digest fetaure
Hello, when browsing the open-iscsi feature list, I found: - PDU header Digest; Does this mean that data digests are not supported? A bugzilla at readhat near mid of 2007 seems to confirm this. I see the performance impact, but is there another reason against implementing it? Can I safely activate it on the target, or will it cause problems? Regards, Ulrich --~--~-~--~~~---~--~~ 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: How to expand a Linux Ext volume.
On Wed, Feb 25, 2009 at 08:14:47AM +0100, Ulrich Windl wrote: Hi, I have a related question: Some of the modern SAN disk systems allow a LUN resize. Does open-iscsi support resized disks in any way? I mean: Will the kernel detect that the disk has a new size? That depends on the iSCSI targets. Some send an SCSI Asynchronous Event and the iscsi daemon asks the kernel to execute READ CAPACITY which then can then find the new size and register it. So once you re-sized the disk, your iscsi-initiator would automatically get notified (within seconds) and your disk would show bigger disk size. If the iSCSI target does not send that (AEN), it is up to you to initiate this. You can do either 'iscsiadm -node -R' or 'echo 1 /sys/block/sdX/device/rescan'. One way to figure out if the kernel is out of sync with the real world is do: SysFS_size=`cat /sys/block/sda/size` SG_size=`sg_readcap /dev/sda | grep Number |sed s'/.*blocks=//'` if [ $SysFS_size != $SG_size ]; then echo 1 /sys/block/sda/device/rescan fi Keep in mind that if you have multipath stacked on top of your block device you also need to tell multipath that your device has grown. This can be done by doing: multipathd -k'resize wwid' (Thought only RHEL5 and SLES11 have this support). --~--~-~--~~~---~--~~ 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: Q: - PDU header Digest fetaure
On Wed, Feb 25, 2009 at 11:39:42AM +0100, Ulrich Windl wrote: Hello, when browsing the open-iscsi feature list, I found: - PDU header Digest; Does this mean that data digests are not supported? A bugzilla at readhat near mid I am quite sure it is supported. of 2007 seems to confirm this. Could you be more specific about the bugzilla number? Is the bugzilla in question accessible to you? I see the performance impact, but is there another reason against implementing it? None. It should be implemented. Can I safely activate it on the target, or will it cause problems? You can activate it on the target. If you see problems, please do report it. --~--~-~--~~~---~--~~ 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: Q: - PDU header Digest fetaure
On 25 Feb 2009 at 8:55, Konrad Rzeszutek wrote: On Wed, Feb 25, 2009 at 11:39:42AM +0100, Ulrich Windl wrote: Hello, when browsing the open-iscsi feature list, I found: - PDU header Digest; Does this mean that data digests are not supported? A bugzilla at readhat near mid I am quite sure it is supported. of 2007 seems to confirm this. Could you be more specific about the bugzilla number? Is the bugzilla in question accessible to you? Hi, I found it with google: bugzilla.redhat.com, bug 245792, comment #6 Regards, Ulrich --~--~-~--~~~---~--~~ 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 1/2 2.6.29-rc] libiscsi - change iscsi_session_failure() to take iscsi_session pointer
Karen Xie wrote: [PATCH 1/2 2.6.29-rc] libiscsi - change iscsi_session_failure() to take iscsi_session pointer From: Karen Xie k...@chelsio.com I guess the From: got messed up. I am not sure if James cares or not. James, I actually wrote the patch for Karen, and she has been using and testing it out with her patches so that is why/how my signed off is first but the From: above has her. change iscsi_session_failure() to take a pointer to iscsi_session instead of iscsi_cls_session. Signed-off-by: Mike Christiemicha...@cs.wisc.edu Signed-off-by: Karen Xie k...@chelsio.com --~--~-~--~~~---~--~~ 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 2/2 2.6.29-rc] cxgb3i - add handling of chip reset
Karen Xie wrote:
[PATCH 2/2 2.6.29-rc] cxgb3i - add support of chip reset
From: Karen Xie k...@chelsio.com
The cxgb3 driver would reset the chip due to an EEH event or a fatal error
and notifies the upper layer modules (iscsi, rdma).
Upon receiving the notification the cxgb3i driver would
- close all the iscsi tcp connections and mark the associated sessions as
failed due to connection error,
- re-initialize its offload functions,
- re-initialize the chip's ddp functions.
The iscsi error recovery mechanism will re-establish the tcp connection after
reset.
This patch requires the the following cxgb3 patch in the linux-next git tree
(http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=cb0bc205959bf8c60acae9c71f3da0597e756f8e).
static inline int ddp_find_unused_entries(struct cxgb3i_ddp_info *ddp,
@@ -439,14 +444,15 @@ EXPORT_SYMBOL_GPL(cxgb3i_ddp_tag_reserve);
* @tag: ddp tag
* ddp cleanup for a given ddp tag and release all the resources held
*/
-void cxgb3i_ddp_tag_release(struct t3cdev *tdev, u32 tag)
+int cxgb3i_ddp_tag_release(struct t3cdev *tdev, u32 tag)
{
struct cxgb3i_ddp_info *ddp = tdev-ulp_iscsi;
u32 idx;
+ int err = -EINVAL;
if (!ddp) {
ddp_log_error(release ddp tag 0x%x, ddp NULL.\n, tag);
- return;
+ return err;
}
idx = (tag PPOD_IDX_SHIFT) ddp-idx_mask;
@@ -457,17 +463,26 @@ void cxgb3i_ddp_tag_release(struct t3cdev *tdev, u32
tag)
if (!gl) {
ddp_log_error(release ddp 0x%x, idx 0x%x, gl NULL.\n,
tag, idx);
- return;
+ return err;
}
npods = (gl-nelem + PPOD_PAGES_MAX - 1) PPOD_PAGES_SHIFT;
+ if (!npods) {
+ ddp_log_error(release ddp 0x%x, 0x%x, gl elem %u.\n,
+ tag, idx, gl-nelem);
+ return err;
+ }
ddp_log_debug(ddp tag 0x%x, release idx 0x%x, npods %u.\n,
tag, idx, npods);
- clear_ddp_map(ddp, idx, npods);
+ if (clear_ddp_map(ddp, tag, idx, npods) == npods)
+ err = 0;
ddp_unmark_entries(ddp, idx, npods);
cxgb3i_ddp_release_gl(gl, ddp-pdev);
If this fails, do we leak this memory?
When is ddp_release called? Would it be called to clean up in situati
this could fail?
+/**
+ * cxgb3i_adapter_remove - release all the resources held and cleanup any
+ * h/w settings
The docbook comment for the function description should only be one
line. I think you did this in some other places.
-void cxgb3i_conn_closing(struct s3_conn *c3cn)
+void cxgb3i_conn_closing(struct s3_conn *c3cn, int error)
{
struct iscsi_conn *conn;
read_lock(c3cn-callback_lock);
conn = c3cn-user_data;
- if (conn c3cn-state != C3CN_STATE_ESTABLISHED)
- iscsi_conn_failure(conn, ISCSI_ERR_CONN_FAILED);
+ if (conn c3cn-state != C3CN_STATE_ESTABLISHED) {
+ if (error)
+ iscsi_session_failure(conn-session,
+ ISCSI_ERR_CONN_FAILED);
+ else
+ iscsi_conn_failure(conn, ISCSI_ERR_CONN_FAILED);
+ }
read_unlock(c3cn-callback_lock);
If you have a ref to the conn, you can just use iscsi_conn_failure here.
I thought when you got the pci error event you were just going to use
the host session iter and loop over the session and fail them.
--~--~-~--~~~---~--~~
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 2/2 2.6.29-rc] cxgb3i - add handling of chip reset
Some other comments about the host and snic allocation.
Karen Xie wrote:
+/**
+ * cxgb3i_adapter_open - initiate or update a s3 adapter structure and
+ * any h/w settings
+ * @t3dev: t3cdev adapter
+ */
+static inline int adapter_update(struct cxgb3i_adapter *snic)
The function name and comment got out of sync.
-void cxgb3i_adapter_remove(struct t3cdev *t3dev)
+void cxgb3i_adapter_open(struct t3cdev *t3dev)
{
- int i;
- struct cxgb3i_adapter *snic;
+ struct cxgb3i_adapter *snic = cxgb3i_adapter_find_by_tdev(t3dev);
+ int err;
- /* remove from the list */
- write_lock(cxgb3i_snic_rwlock);
- list_for_each_entry(snic, cxgb3i_snic_list, list_head) {
- if (snic-tdev == t3dev) {
- list_del(snic-list_head);
- break;
- }
+ if (snic)
+ err = adapter_update(snic);
+ else {
+ snic = kzalloc(sizeof(*snic), GFP_KERNEL);
+ if (snic) {
+ spin_lock_init(snic-lock);
+ snic-tdev = t3dev;
+ err = adapter_add(snic);
+ } else
+ err = -ENOMEM;
Does the snic represent the actual card. So if I had a dual ported card,
I would have one snic and then have multple shosts/cxgb3i_hba for each
port right?
It seemed strange because cxgb3i_hba_host_add sets the shost's parent to
the pci device, and we get the pci device from the snic-pdev. And so I
thought we see a pci device per port, so we would also should have a
snic per port?
--~--~-~--~~~---~--~~
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: Q: - PDU header Digest fetaure
Ulrich Windl wrote: Hello, when browsing the open-iscsi feature list, I found: - PDU header Digest; Is that from suse's docs or open-iscsi.orgs? Does this mean that data digests are not supported? A bugzilla at readhat near mid of 2007 seems to confirm this. Data digests were working but when upstream did the scatterlist changes to the kernel it broke data digests. We have not found the cause yet. For Red Hat, they do not support them for different reasons depending on the version and arch. For example in RHEL5, the big endien crypto digest code is busted. It needs a fix from upstream, and I think in general there is still some other bugs in the digest code. I see the performance impact, but is there another reason against implementing it? Can I safely activate it on the target, or will it cause problems? Another reason a lot of distros do not support it is because a common problem we always hit is that users will write out some data, then start modifying it again. But the kernel will normally not do do a sync write when you do a write. So once the write() returns, the kernel is still sending it through the caches, block, scsi, and iscsi layers. If you are writing to the data while the it is working its way through the iscsi layers, the iscsi layer could have done the digest calculation, then you could modify it and now when the target checks it the digest check will fail. And so this happens over and over and you get digest errors all over the place and the iscsi layers fire their error handling and retry and retry, and in the end they just say forget it and do not support data digests. --~--~-~--~~~---~--~~ 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 2/2 2.6.29-rc] cxgb3i - add handling of chip reset
-Original Message-
From: Mike Christie [mailto:micha...@cs.wisc.edu]
Sent: Wednesday, February 25, 2009 9:30 AM
To: Karen Xie
Cc: open-iscsi@googlegroups.com; linux-s...@vger.kernel.org;
james.bottom...@hansenpartnership.com
Subject: Re: [PATCH 2/2 2.6.29-rc] cxgb3i - add handling of chip reset
Some other comments about the host and snic allocation.
Karen Xie wrote:
+/**
+ * cxgb3i_adapter_open - initiate or update a s3 adapter structure
and
+ * any h/w settings
+ * @t3dev: t3cdev adapter
+ */
+static inline int adapter_update(struct cxgb3i_adapter *snic)
The function name and comment got out of sync.
[Karen] Thanks, will fix it.
-void cxgb3i_adapter_remove(struct t3cdev *t3dev)
+void cxgb3i_adapter_open(struct t3cdev *t3dev)
{
- int i;
- struct cxgb3i_adapter *snic;
+ struct cxgb3i_adapter *snic =
cxgb3i_adapter_find_by_tdev(t3dev);
+ int err;
- /* remove from the list */
- write_lock(cxgb3i_snic_rwlock);
- list_for_each_entry(snic, cxgb3i_snic_list, list_head) {
- if (snic-tdev == t3dev) {
- list_del(snic-list_head);
- break;
- }
+ if (snic)
+ err = adapter_update(snic);
+ else {
+ snic = kzalloc(sizeof(*snic), GFP_KERNEL);
+ if (snic) {
+ spin_lock_init(snic-lock);
+ snic-tdev = t3dev;
+ err = adapter_add(snic);
+ } else
+ err = -ENOMEM;
Does the snic represent the actual card. So if I had a dual ported card,
I would have one snic and then have multple shosts/cxgb3i_hba for each
port right?
[Karen] Yes.
It seemed strange because cxgb3i_hba_host_add sets the shost's parent to
the pci device, and we get the pci device from the snic-pdev. And so I
thought we see a pci device per port, so we would also should have a
snic per port?
[Karen] Each port/cxgb3i_hba has a pointer point back to the
snic/adapter. So one snic per adapter, each snic contains one or more
ports, each port corresponds to one shost.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Can I have multiple Windows Hosts accessing the same IP SAN Volume?
I have one stone fly storage concentrator and 2 windows host and Linux host are attached with it. Can I have multiple Windows Hosts accessing the same IP SAN Volume? Thanks David --~--~-~--~~~---~--~~ 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: Can I have multiple Windows Hosts accessing the same IP SAN Volume?
Through the use of StoneFlys Access Control List, you can assign multiple Hosts access to the same volume. The options available are Read Only or Read/Write Access. If more than one host has Read/Write access to the same volume it is very important that only one Host at a time accesses a particular volume. This can be useful if using the volume in a Cluster for the quorum disk. Can also be used if there are Volume managment tools in place such as Veritas Volume Manager. Data/Volume corruption could occur if safeguards are not implemented! The safest method to ensure only one host is accessing a shared volume at the same time is to run a Volume Manager program (like Veritas' Volume Manager or Sanbolics™ Kayo). Another option is to script the mounting and unmounting of the Volume using Microsofts™ utility Diskpart.exe. Thanks Storage Solution Group. On Feb 25, 11:33 pm, daviddiz...@gmail.com daviddiz...@gmail.com wrote: I have one stone fly storage concentrator and 2 windows host and Linux host are attached with it. Can I have multiple Windows Hosts accessing the same IP SAN Volume? Thanks David --~--~-~--~~~---~--~~ 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: Can anybody give Stone Fly OptiSAN Specifications
Hi Prince, here are some specifications for stonefly optisan. IT Supports 16 SAS or SATA Disk Drives and allows Expansion up to 256 Disks.It is having Dual Active-Active RAID Controllers with Transparent Failover and Failback Operation and Out-of-Band Ethernet Interface for Remote Status Monitoring Configuration,Capable of RAID Levels 0, 1, 0+1, 3, 5, 6, 10, 30, 50, 60 and JBOD. It support volume encryption mirroring. you can get more features from http://www.stonefly.com/products/optisan/ Thanks Regards Storage Solution Group. On Feb 26, 12:17 am, prince.josep...@gmail.com prince.josep...@gmail.com wrote: I heard about a stone fly product called Stone Fly OptiSAN Cluster HA. Can anybody give specifications for this product, is this a stable product compared to other IP SAN's in market. Thanks in advance Prince. --~--~-~--~~~---~--~~ 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 boot without ibft but using ibft sysfs code
On Wed, Feb 25, 2009 at 12:25:44PM -0600, Mike Christie wrote: Hey Konrad and other boot guys, If we have a driver that does not support ibft, but we need to somehow export the iscsi info used for boot to userspace how do you think we should go about this? I was thinking that 1. We could libify some of the ibft sysfs code, so drivers could call some helper to export its boot info in a common place. The driver would basically talk to its firmware to get the boot info, then call something like iscsi_boot_sysfs_add_target_info() which would expose it in sysfs in a common place. I like this one, but with a twist - the subsystem would have to be more generic instead of being called 'ibft'. And it means reworking the ibft driver so that it registers under this sysfs class and provides the boot data the same way these other drivers would do. This would also allow multiple iBFT structures to be exported in case you have multiple NICs - which is something that on the gPXE mailing list was thrown around. I think 'iscsi_boot' as a name sounds appealing. Perhaps retain the same directory structure (that ibft has now) and have the drivers (ibft + other drivers) call such '*_add_target_info', '*_add_nic_info', etc? This is nice because the tools only have to look in one place, but I am not sure if this type of stuff can also go under the /sys/firmware dir. True. Would have to change the parent tree. Maybe to to /sys/boot' (or /sys/iscsi_boot?) --~--~-~--~~~---~--~~ 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 boot without ibft but using ibft sysfs code
On Wednesday 25 February 2009 22:47:12 Konrad Rzeszutek wrote: This is nice because the tools only have to look in one place, but I am not sure if this type of stuff can also go under the /sys/firmware dir. True. Would have to change the parent tree. Maybe to to /sys/boot' (or /sys/iscsi_boot?) We're still talking about information extracted from the firmware, whether via the iBFT or via vendor-specific mechanisms; /sys/firmware sounds appropriate to me at least. Michael --~--~-~--~~~---~--~~ 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: Q: - PDU header Digest feature
On 25 Feb 2009 at 11:38, Mike Christie wrote: Ulrich Windl wrote: Hello, when browsing the open-iscsi feature list, I found: - PDU header Digest; Is that from suse's docs or open-iscsi.orgs? Hi Mike, it was from the README you had sent me recently. Inside it's dated Mar 14, 2008. Does this mean that data digests are not supported? A bugzilla at readhat near mid of 2007 seems to confirm this. Data digests were working but when upstream did the scatterlist changes to the kernel it broke data digests. We have not found the cause yet. Hmm: I thought it's all about network packages: You put SCSI commands into network packets, and then checksum the data in the package. When receiving, you check the packet, then extract the SCSI commands. I don't see where the SCSI layer could invalidate network packets here. But I really don't have a deep insight. For Red Hat, they do not support them for different reasons depending on the version and arch. For example in RHEL5, the big endien crypto digest code is busted. It needs a fix from upstream, and I think in general there is still some other bugs in the digest code. OK, naively I's assume that if digests are enabled, but broken, nothing will work (all packets rejected), and the syslog should complain a lot. Am I right with this? I see the performance impact, but is there another reason against implementing it? Can I safely activate it on the target, or will it cause problems? Another reason a lot of distros do not support it is because a common problem we always hit is that users will write out some data, then start modifying it again. But the kernel will normally not do do a sync write when you do a write. So once the write() returns, the kernel is still sending it through the caches, block, scsi, and iscsi layers. If you are writing to the data while the it is working its way through the iscsi layers, the iscsi layer could have done the digest calculation, then you could modify it and now when the target checks it the digest check will fail. And so this happens over and over and you get digest errors all over the place and the iscsi layers fire their error handling and retry and retry, and in the end they just say forget it and do not support data digests. So information flow seems to be a bit different from what I was expecting. I thought the physical write is when the kernel issues the SCSI command write to the HBA (which should be iSCSI here). ISCSI would then build a network packet from the SCSI command and transfer it, optionally with digests attached. Regards, Ulrich --~--~-~--~~~---~--~~ 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: Can anybody give Stone Fly OptiSAN Specifications
On 25 Feb 2009 at 11:17, prince.josep...@gmail.com wrote: I heard about a stone fly product called Stone Fly OptiSAN Cluster HA. Can anybody give specifications for this product, is this a stable product compared to other IP SAN's in market. Hi! I think the most natural place to ask for product specifications is the vendor's site, specifically not the iSCSI list. Maybe you just wanted to make product promotion; in that case it was a poor attempt ;-) Regards, Ulrich Thanks in advance Prince. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
