open-iscsi ideal filesystem?
Hey all, I was wondering if anyone out there had tested open-iscsi with a variety of Linux filesystems to see what works best. Currently I am using the ext3 fs and for months now have been suffering problems. Anytime the iSCSI connection is dropped a variety of bad things can happen. The fs will get corrupted, I/O errors will occur when doing shell operations on the volume, kernel oopses will occur, and so on. Most of this is probably related to the state of the iSCSI device. However tools like e2fsck take forever to fix a volume if it is 500 Gigs and up. Are there any suggestions out there for alternatives? Or are there better ext3 tools that can fix the fs quicker? How are the rest of you dealing with loss of connection and data corruption? --~--~-~--~~~---~--~~ 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: open-iscsi ideal filesystem?
On Tue, Aug 26, 2008 at 11:37:46PM -0700, An Oneironaut wrote: Hey all, I was wondering if anyone out there had tested open-iscsi with a variety of Linux filesystems to see what works best. Currently I am using the ext3 fs and for months now have been suffering problems. Anytime the iSCSI connection is dropped a variety of bad things can happen. The fs will get corrupted, I/O errors will occur when doing shell operations on the volume, kernel oopses will occur, and so on. Most of this is probably related to the state of the iSCSI device. However tools like e2fsck take forever to fix a volume if it is 500 Gigs and up. Are there any suggestions out there for alternatives? Or are Use multipath and make your iSCSI target use the 'queue_if_no_path' configuration. Then you can use any filesystem on top of multipath and it won't matter that the underlaying connection is disconnected - the machine will just block the I/Os until it the iSCSI target is reconnected. there better ext3 tools that can fix the fs quicker? How are the rest of you dealing with loss of connection and data corruption? multipath. --~--~-~--~~~---~--~~ 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: open-iscsi ideal filesystem?
Konrad Rzeszutek schrieb: On Tue, Aug 26, 2008 at 11:37:46PM -0700, An Oneironaut wrote: Hey all, I was wondering if anyone out there had tested open-iscsi with a variety of Linux filesystems to see what works best. Currently I am using the ext3 fs and for months now have been suffering problems. Anytime the iSCSI connection is dropped a variety of bad things can happen. The fs will get corrupted, I/O errors will occur when doing shell operations on the volume, kernel oopses will occur, and so on. Most of this is probably related to the state of the iSCSI device. However tools like e2fsck take forever to fix a volume if it is 500 Gigs and up. Are there any suggestions out there for alternatives? Or are Use multipath and make your iSCSI target use the 'queue_if_no_path' configuration. Then you can use any filesystem on top of multipath and it won't matter that the underlaying connection is disconnected - the machine will just block the I/Os until it the iSCSI target is reconnected. there better ext3 tools that can fix the fs quicker? How are the rest of you dealing with loss of connection and data corruption? multipath. I think the easiest it to increase the node.session.timeo.replacement_timeout in /etc/iscsi/iscsid.conf to something more than default 120 seconds (which means that the connection is dropped after 2 minutes; if you want to upgrade your target server and change the cabling, you may need more time than two minutes). -- Tomasz Chmielewski http://wpkg.org --~--~-~--~~~---~--~~ 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: Build problems with 869.2
On Aug 27, 1:34 am, Erez Zilber [EMAIL PROTECTED] wrote: If you don't plan to use iSER, you can remove the line the loads it in the init script (where it says something like modprobe ib_iser). If you do plan to use iSER, there's also a solution for that. Erez Rather than having to modify the init scripts on my machines, can I just comment out 'CONFIG_INFINIBAND_ISER=m' in the kernel config next time I rebuild my kernel? Or will I still see those warnings without iser in the kernel? --~--~-~--~~~---~--~~ 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: open-iscsi ideal filesystem?
Ok,
To answer the questions. The timeout time I have setup is 600
seconds which is the limit of what I'd like to do. The problem with a
long time out is that every operation that could possibly happen on
that mount will freeze up for ${TIMEOUT} seconds. The worst one is
reload which will freeze up, in the system I am working on it proves
to be a major problem and I just can't push the timeout too far.
Anyways what about the case where scsi device goes down at 2am and I
don't see it till 10am the next day?
Instead what I have in place now is that the scsi connection will be
torn down and the mount will be remounted as read only. I then have a
background script that keeps checking the iscsi device until it is
back up again. Once that happens it will restore the connection.
As far as multipath goes. Is there any better documentation for
this queue? How big is the queue? Is it a configurable size? Why is
the data only queue in multi-path and not the regular operation mode?
Or rather why isn't there an option?
I appreciate the comments.
Thanks.
On Aug 27, 6:29 am, Tomasz Chmielewski [EMAIL PROTECTED] wrote:
Konrad Rzeszutek schrieb:
On Tue, Aug 26, 2008 at 11:37:46PM -0700, An Oneironaut wrote:
Hey all,
I was wondering if anyone out there had tested open-iscsi with a
variety of Linux filesystems to see what works best. Currently I am
using the ext3 fs and for months now have been suffering problems.
Anytime the iSCSI connection is dropped a variety of bad things can
happen. The fs will get corrupted, I/O errors will occur when doing
shell operations on the volume, kernel oopses will occur, and so on.
Most of this is probably related to the state of the iSCSI device.
However tools like e2fsck take forever to fix a volume if it is 500
Gigs and up.
Are there any suggestions out there for alternatives? Or are
Use multipath and make your iSCSI target use the 'queue_if_no_path'
configuration.
Then you can use any filesystem on top of multipath and it won't matter
that the underlaying connection is disconnected - the machine will
just block the I/Os until it the iSCSI target is reconnected.
there better ext3 tools that can fix the fs quicker? How are the rest
of you dealing with loss of connection and data corruption?
multipath.
I think the easiest it to increase the
node.session.timeo.replacement_timeout in /etc/iscsi/iscsid.conf to
something more than default 120 seconds (which means that the connection
is dropped after 2 minutes; if you want to upgrade your target server
and change the cabling, you may need more time than two minutes).
--
Tomasz Chmielewskihttp://wpkg.org
--~--~-~--~~~---~--~~
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: Odd behaviour during unidirectional CHAP authentication
Thanks Shyam. So in this case target replies with NONE as it has choosen NONE between CHAP and NONE. Here initiator is asking for authentication and Target is not ready for authentication. In this scenario authentication should fail. Right? To make authentication strict, initiator should only pass CHAP as Authentication parameter rather than passing CHAP,NONE. So if target is not supporting CHAP it will reply with Reject and auth will fail. On the other side, if initiator doesn't set CHAP and target sets CHAP, Authentication Fails, which is perfect. Thanks Nand On Aug 27, 1:36 pm, [EMAIL PROTECTED] wrote: Nandkumar wrote: Here is what initiator and taget passes to each other while iscsi negotiation phase. Assuming CHAP is only enabled on initiator and not on target. 1) Initiator pass CHAP,NONE as Authentication parameter. 2) Target replies with NONE. 3) Both will settle on NONE as Authentication parameter. The negotiation is succeding with None as the parameter because of the following text from the rfc. The target MUST reply with the first option in the list it supports and is allowed to use for the specific initiator unless it does not support any, in which case it MUST answer with Reject (see Section 5.2 Text Mode Negotiation). So, since there is no reject from the Target which supports None as the authentication parameter the login will succeed. Thanks, Shyam Iyer --~--~-~--~~~---~--~~ 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: open-iscsi ideal filesystem?
Documentation section of http://christophe.varoqui.free.fr/ will give
you enough insight of multipath.
After installing multipath tools, you can find info about each
parameter of multipath.conf in
/usr/share/doc/device-mapper-multipath-0.4.7/multipath.conf.annotated
file.
Thanks
Nankdumar
On Aug 28, 12:47 am, An Oneironaut [EMAIL PROTECTED] wrote:
Ok,
To answer the questions. The timeout time I have setup is 600
seconds which is the limit of what I'd like to do. The problem with a
long time out is that every operation that could possibly happen on
that mount will freeze up for ${TIMEOUT} seconds. The worst one is
reload which will freeze up, in the system I am working on it proves
to be a major problem and I just can't push the timeout too far.
Anyways what about the case where scsi device goes down at 2am and I
don't see it till 10am the next day?
Instead what I have in place now is that the scsi connection will be
torn down and the mount will be remounted as read only. I then have a
background script that keeps checking the iscsi device until it is
back up again. Once that happens it will restore the connection.
As far as multipath goes. Is there any better documentation for
this queue? How big is the queue? Is it a configurable size? Why is
the data only queue in multi-path and not the regular operation mode?
Or rather why isn't there an option?
I appreciate the comments.
Thanks.
On Aug 27, 6:29 am, Tomasz Chmielewski [EMAIL PROTECTED] wrote:
Konrad Rzeszutek schrieb:
On Tue, Aug 26, 2008 at 11:37:46PM -0700, An Oneironaut wrote:
Hey all,
I was wondering if anyone out there had tested open-iscsi with a
variety of Linux filesystems to see what works best. Currently I am
using the ext3 fs and for months now have been suffering problems.
Anytime the iSCSI connection is dropped a variety of bad things can
happen. The fs will get corrupted, I/O errors will occur when doing
shell operations on the volume, kernel oopses will occur, and so on.
Most of this is probably related to the state of the iSCSI device.
However tools like e2fsck take forever to fix a volume if it is 500
Gigs and up.
Are there any suggestions out there for alternatives? Or are
Use multipath and make your iSCSI target use the 'queue_if_no_path'
configuration.
Then you can use any filesystem on top of multipath and it won't matter
that the underlaying connection is disconnected - the machine will
just block the I/Os until it the iSCSI target is reconnected.
there better ext3 tools that can fix the fs quicker? How are the rest
of you dealing with loss of connection and data corruption?
multipath.
I think the easiest it to increase the
node.session.timeo.replacement_timeout in /etc/iscsi/iscsid.conf to
something more than default 120 seconds (which means that the connection
is dropped after 2 minutes; if you want to upgrade your target server
and change the cabling, you may need more time than two minutes).
--
Tomasz Chmielewskihttp://wpkg.org- Hide quoted text -
- Show quoted text -
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[PATCH 3/4 2.6.28] open-iscsi - support for digest offload and payload DDP
[PATCH 3/4 2.6.28] open-iscsi - support for digest offload and payload DDP.
From: Karen Xie [EMAIL PROTECTED]
Added PDU digest offload and payload direct-placement support in
open-iscsi.
Signed-off-by: Karen Xie [EMAIL PROTECTED]
---
drivers/scsi/iscsi_tcp.c| 56 ---
drivers/scsi/iscsi_tcp.h| 14 +
drivers/scsi/libiscsi.c | 54 +++---
include/scsi/iscsi_if.h |1 +
include/scsi/libiscsi.h |2 +
include/scsi/scsi_transport_iscsi.h |9 ++
6 files changed, 106 insertions(+), 30 deletions(-)
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 2a2f009..ec73a31 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -97,7 +97,7 @@ static int iscsi_tcp_hdr_recv_done(struct iscsi_tcp_conn
*tcp_conn,
* data is copied to the indicated sg entry, at the given
* offset.
*/
-static inline void
+void
iscsi_tcp_segment_init_sg(struct iscsi_segment *segment,
struct scatterlist *sg, unsigned int offset)
{
@@ -107,6 +107,7 @@ iscsi_tcp_segment_init_sg(struct iscsi_segment *segment,
segment-total_size - segment-total_copied);
segment-data = NULL;
}
+EXPORT_SYMBOL_GPL(iscsi_tcp_segment_init_sg);
/**
* iscsi_tcp_segment_map - map the current S/G page
@@ -117,7 +118,7 @@ iscsi_tcp_segment_init_sg(struct iscsi_segment *segment,
* because the iscsi passthrough and internal IO paths will never use high
* mem pages.
*/
-static inline void
+void
iscsi_tcp_segment_map(struct iscsi_segment *segment, int recv)
{
struct scatterlist *sg;
@@ -143,8 +144,9 @@ iscsi_tcp_segment_map(struct iscsi_segment *segment, int
recv)
segment-sg_mapped = kmap_atomic(sg_page(sg), KM_SOFTIRQ0);
segment-data = segment-sg_mapped + sg-offset + segment-sg_offset;
}
+EXPORT_SYMBOL_GPL(iscsi_tcp_segment_map);
-static inline void
+void
iscsi_tcp_segment_unmap(struct iscsi_segment *segment)
{
debug_tcp(iscsi_tcp_segment_unmap %p\n, segment);
@@ -156,6 +158,7 @@ iscsi_tcp_segment_unmap(struct iscsi_segment *segment)
segment-data = NULL;
}
}
+EXPORT_SYMBOL_GPL(iscsi_tcp_segment_unmap);
/*
* Splice the digest buffer into the buffer
@@ -376,6 +379,9 @@ static inline int
iscsi_tcp_dgst_verify(struct iscsi_tcp_conn *tcp_conn,
struct iscsi_segment *segment)
{
+ if (tcp_conn-iscsi_conn-session-tt-caps CAP_DIGEST_OFFLOAD)
+ return (segment-status ISCSI_SEGMENT_DGST_ERR) ? 0 : 1;
+
if (!segment-digest_len)
return 1;
@@ -448,7 +454,7 @@ iscsi_segment_seek_sg(struct iscsi_segment *segment,
* function is called we do not yet know the final size of the header and want
* to delay the digest processing until we know that.
*/
-static void
+void
iscsi_tcp_hdr_recv_prep(struct iscsi_tcp_conn *tcp_conn)
{
debug_tcp(iscsi_tcp_hdr_recv_prep(%p%s)\n, tcp_conn,
@@ -457,6 +463,7 @@ iscsi_tcp_hdr_recv_prep(struct iscsi_tcp_conn *tcp_conn)
tcp_conn-in.hdr_buf, sizeof(struct iscsi_hdr),
iscsi_tcp_hdr_recv_done, NULL);
}
+EXPORT_SYMBOL_GPL(iscsi_tcp_hdr_recv_prep);
/*
* Handle incoming reply to any other type of command
@@ -486,7 +493,8 @@ iscsi_tcp_data_recv_prep(struct iscsi_tcp_conn *tcp_conn)
struct iscsi_conn *conn = tcp_conn-iscsi_conn;
struct hash_desc *rx_hash = NULL;
- if (conn-datadgst_en)
+ if (conn-datadgst_en
+ !(conn-session-tt-caps CAP_DIGEST_OFFLOAD))
rx_hash = tcp_conn-rx_hash;
iscsi_segment_init_linear(tcp_conn-in.segment,
@@ -497,7 +505,7 @@ iscsi_tcp_data_recv_prep(struct iscsi_tcp_conn *tcp_conn)
/*
* must be called with session lock
*/
-static void
+void
iscsi_tcp_cleanup_task(struct iscsi_conn *conn, struct iscsi_task *task)
{
struct iscsi_tcp_task *tcp_task = task-dd_data;
@@ -521,6 +529,7 @@ iscsi_tcp_cleanup_task(struct iscsi_conn *conn, struct
iscsi_task *task)
tcp_task-r2t = NULL;
}
}
+EXPORT_SYMBOL_GPL(iscsi_tcp_cleanup_task);
/**
* iscsi_data_rsp - SCSI Data-In Response processing
@@ -737,7 +746,7 @@ iscsi_tcp_process_data_in(struct iscsi_tcp_conn *tcp_conn,
* by data, the receive buffer is set up to copy the incoming data
* to the correct location.
*/
-static int
+int
iscsi_tcp_hdr_dissect(struct iscsi_conn *conn, struct iscsi_hdr *hdr)
{
int rc = 0, opcode, ahslen;
@@ -793,7 +802,8 @@ iscsi_tcp_hdr_dissect(struct iscsi_conn *conn, struct
iscsi_hdr *hdr)
* we move on to the next scatterlist entry and
* update the digest per-entry.
*/
- if (conn-datadgst_en)
+ if (conn-datadgst_en
+
[PATCH 1/1] open-iscsi - add cxgb3i transport iface
[PATCH 1/1] open-iscsi - add cxgb3i transport iface
From: Karen Xie [EMAIL PROTECTED]
Add cxgb3i transport interface for open-iscsi user space tool.
Signed-off-by: Karen Xie [EMAIL PROTECTED]
---
usr/transport.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/usr/transport.c b/usr/transport.c
index c2edbcc..923766a 100644
--- a/usr/transport.c
+++ b/usr/transport.c
@@ -48,6 +48,13 @@ struct iscsi_transport_template bnx2i = {
.ep_disconnect = ktransport_ep_disconnect,
};
+struct iscsi_transport_template cxgb3i = {
+ .name = cxgb3i,
+ .ep_connect = ktransport_ep_connect,
+ .ep_poll= ktransport_ep_poll,
+ .ep_disconnect = ktransport_ep_disconnect,
+};
+
struct iscsi_transport_template qla4xxx = {
.name = qla4xxx,
};
@@ -56,6 +63,7 @@ static struct iscsi_transport_template
*iscsi_transport_templates[] = {
iscsi_tcp,
iscsi_iser,
bnx2i,
+ cxgb3i,
qla4xxx,
NULL
};
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[PATCH 2/4 2.6.28] cxgb3 - handle ARP replies for private iSCSI IP address
[PATCH 2/4 2.6.28] cxgb3 - handle ARP replies for private iSCSI IP address
From: Karen Xie [EMAIL PROTECTED]
The accelerated iSCSI traffic uses a private IP address unknown to the OS.
The driver has to reply to ARP requests dedicated to the private IP address.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/sge.c | 72 ---
1 files changed, 67 insertions(+), 5 deletions(-)
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
index 1b0861d..2f17cf3 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -36,6 +36,7 @@
#include linux/ip.h
#include linux/tcp.h
#include linux/dma-mapping.h
+#include net/arp.h
#include common.h
#include regs.h
#include sge_defs.h
@@ -1859,6 +1860,54 @@ static void restart_tx(struct sge_qset *qs)
}
/**
+ * cxgb3_arp_process - process an ARP request probing a private IP address
+ * @adapter: the adapter
+ * @skb: the skbuff containing the ARP request
+ *
+ * Check if the ARP request is probing the private IP address
+ * dedicated to iSCSI, generate an ARP reply if so.
+ */
+static void cxgb3_arp_process(struct adapter *adapter, struct sk_buff *skb)
+{
+ struct net_device *dev = skb-dev;
+ struct port_info *pi;
+ struct arphdr *arp;
+ unsigned char *arp_ptr;
+ unsigned char *sha;
+ __be32 sip, tip;
+
+ if (!dev)
+ return;
+
+ skb_reset_network_header(skb);
+ arp = arp_hdr(skb);
+
+ if (arp-ar_op != htons(ARPOP_REQUEST))
+ return;
+
+ arp_ptr = (unsigned char *)(arp + 1);
+ sha = arp_ptr;
+ arp_ptr += dev-addr_len;
+ memcpy(sip, arp_ptr, sizeof(sip));
+ arp_ptr += sizeof(sip);
+ arp_ptr += dev-addr_len;
+ memcpy(tip, arp_ptr, sizeof(tip));
+
+ pi = netdev_priv(dev);
+ if (tip != pi-iscsi_ipv4addr)
+ return;
+
+ arp_send(ARPOP_REPLY, ETH_P_ARP, sip, dev, tip, sha,
+dev-dev_addr, sha);
+
+}
+
+static inline int is_arp(struct sk_buff *skb)
+{
+ return skb-protocol == htons(ETH_P_ARP);
+}
+
+/**
* rx_eth - process an ingress ethernet packet
* @adap: the adapter
* @rq: the response queue that received the packet
@@ -1882,7 +1931,7 @@ static void rx_eth(struct adapter *adap, struct sge_rspq
*rq,
pi = netdev_priv(skb-dev);
if (pi-rx_csum_offload p-csum_valid p-csum == htons(0x)
!p-fragment) {
- rspq_to_qset(rq)-port_stats[SGE_PSTAT_RX_CSUM_GOOD]++;
+ qs-port_stats[SGE_PSTAT_RX_CSUM_GOOD]++;
skb-ip_summed = CHECKSUM_UNNECESSARY;
} else
skb-ip_summed = CHECKSUM_NONE;
@@ -1891,22 +1940,35 @@ static void rx_eth(struct adapter *adap, struct
sge_rspq *rq,
struct vlan_group *grp = pi-vlan_grp;
qs-port_stats[SGE_PSTAT_VLANEX]++;
- if (likely(grp))
+
+ if (likely(grp)) {
if (lro)
lro_vlan_hwaccel_receive_skb(qs-lro_mgr, skb,
grp,
ntohs(p-vlan),
p);
- else
+ else {
+ if (unlikely(pi-iscsi_ipv4addr
+is_arp(skb))) {
+ unsigned short vtag = ntohs(p-vlan)
+ VLAN_VID_MASK;
+ skb-dev = vlan_group_get_device(grp,
+vtag);
+ cxgb3_arp_process(adap, skb);
+ }
__vlan_hwaccel_rx(skb, grp, ntohs(p-vlan),
rq-polling);
- else
+ }
+ } else
dev_kfree_skb_any(skb);
} else if (rq-polling) {
if (lro)
lro_receive_skb(qs-lro_mgr, skb, p);
- else
+ else {
+ if (unlikely(pi-iscsi_ipv4addr is_arp(skb)))
+ cxgb3_arp_process(adap, skb);
netif_receive_skb(skb);
+ }
} else
netif_rx(skb);
}
--~--~-~--~~~---~--~~
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
