iSCSI target recommendation
Hey all. Could anyone suggest a good NAS that has about 2 to 6TB of storage which is under 4k? its hard to find out whether these people have tested with open-iscsi or not. So I was hoping some of you out there who had used a storage device within this range would have some opinions. Please tell me if you have any suggestions. Thanks, JD -- 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: iSCSI target recommendation
It doesn't seem like this is a true SAN though.. Any other suggestions? On Mar 26, 12:54 pm, heini66 hein...@googlemail.com wrote: 2010/3/26 An Oneironaut anoneiron...@gmail.com Hey all. Could anyone suggest a good NAS that has about 2 to 6TB of storage which is under 4k? its hard to find out whether these people have tested with open-iscsi or not. So I was hoping some of you out there who had used a storage device within this range would have some opinions. Please tell me if you have any suggestions. Thanks, you might want to have a look ahttp://www.drobo.com/products/drobopro/ drive without hdd's and 19 mounting option 999€. one of the nicest options in my oppionion is the possibillity to put in only 2 2tb hdd's and virtual format it to 16tb. if it runs out of space with first attached hdd's, you'll get an email or smtp notice, that you have to add hdd's. this can be done without shuting the drobo down or taking it offline. an no!!! special tray's or mounts for the additonal hdds's are needed. just open one of the empty slot's and plug hdd into 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-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: Kernel oops on login
Mar 1 21:09:07 localhost kernel: [c026c6c8] sd_probe+0x278/0x3f0 Mar 1 21:09:07 localhost kernel: [c0189e47] sysfs_create_link +0x57/0x150 Mar 1 21:09:07 localhost kernel: [c0230c57] driver_probe_device +0x87/0x190 Mar 1 21:09:07 localhost kernel: [c0331fc1] klist_next+0x51/0xb0 Mar 1 21:09:07 localhost kernel: [c022ff24] bus_for_each_drv +0x44/0x70 Mar 1 21:09:07 localhost kernel: [c0230e19] device_attach +0x79/0x80 Mar 1 21:09:07 localhost kernel: [c0230d60] __device_attach +0x0/0x10 Mar 1 21:09:07 localhost kernel: [c022fe95] bus_attach_device +0x45/0x90 Mar 1 21:09:07 localhost kernel: [c022eb93] device_add+0x493/0x560 Mar 1 21:09:07 localhost kernel: [c0268502] scsi_sysfs_add_sdev +0x32/0x230 Mar 1 21:09:07 localhost kernel: [c02665bd] scsi_probe_and_add_lun +0x95d/0x980 Mar 1 21:09:07 localhost kernel: [c0266e91] __scsi_scan_target +0x491/0x5f0 Mar 1 21:09:07 localhost kernel: [c0166dcb] mntput_no_expire+0x1b/ 0x70 Mar 1 21:09:07 localhost kernel: [c015bac3] link_path_walk +0x63/0xc0 Mar 1 21:09:07 localhost kernel: [c02676a6] scsi_scan_target +0xb6/0xe0 Mar 1 21:09:07 localhost kernel: [f8a008fa] iscsi_user_scan_session +0x9a/0xb0 [scsi_transport_iscsi] Mar 1 21:09:07 localhost kernel: [f8a00820] iscsi_user_scan +0x0/0x30 [scsi_transport_iscsi] Mar 1 21:09:07 localhost kernel: [f8a00860] iscsi_user_scan_session +0x0/0xb0 [scsi_transport_iscsi] Mar 1 21:09:07 localhost kernel: [c022dd42] device_for_each_child +0x22/0x40 Mar 1 21:09:07 localhost kernel: [f8a00820] iscsi_user_scan +0x0/0x30 [scsi_transport_iscsi] Mar 1 21:09:07 localhost kernel: [f8a00843] iscsi_user_scan +0x23/0x30 [scsi_transport_iscsi] Mar 1 21:09:07 localhost kernel: [c026818b] store_scan+0xbb/0xf0 Mar 1 21:09:07 localhost kernel: [c013b614] __alloc_pages +0x64/0x2f0 Mar 1 21:09:07 localhost kernel: [c02680d0] store_scan+0x0/0xf0 Mar 1 21:09:07 localhost kernel: [c0232196] class_device_attr_store +0x26/0x40 Mar 1 21:09:07 localhost kernel: [c0188151] sysfs_write_file +0xb1/0x110 Mar 1 21:09:07 localhost kernel: [c01880a0] sysfs_write_file +0x0/0x110 Mar 1 21:09:07 localhost kernel: [c0153820] vfs_write+0xa0/0x140 Mar 1 21:09:07 localhost kernel: [c0153da1] sys_write+0x41/0x70 Mar 1 21:09:07 localhost kernel: [c010280e] sysenter_past_esp+0x5f/ 0x85 Mar 1 21:09:07 localhost kernel: === Mar iscsiadm: got read error (0/0), daemon died? iscsiadm: Could not login to [iface: default, target: iqn. 1999-02.com.nexsan:p0:sataboy:01731a5a, portal: 172.19.151.169,3260]: iscsiadm: initiator reported error (18 - could not communicate to iscsid) bash-2.05b# 1 21:09:07 localhost kernel: Code: 74 26 00 8d bc 27 00 00 00 00 83 ec 28 89 5c 24 18 8b 5c 24 2c 89 74 24 1c 89 7c 24 20 89 6c 24 24 89 d5 89 4c 24 08 89 4424 0c 8b 42 08 83 c0 68 e8 94 a2 1a 00 31 c0 b9 ff ff ff ff 8b 7c 24 Mar 1 21:09:07 localhost kernel: EIP: [c0189241] create_dir +0x21/0x190 SS:ESP 0068:f7191b7c In addition. Even if I remove the flash drive, when I continually log in and logout of my remote SCSI device the device nodes keep incrementing. In the past it would just stay on the same device nodes unless the scsi device's configuration changed. Ive added a log of this behavior in the uploads section. The file is incDevNodes. Can anyone help? Does anyone have any input on this? My build is working fine and my kernel is being patched. Here are my system stats again: 1. Kernel: 2.6.22.10 2. Open-Iscsi Version: iscsiadm version 2.0-871 3. Nexsan SCSI device Thanks, JD On Feb 25, 7:05 pm, An Oneironaut anoneiron...@gmail.com wrote: Hey all, I'm running open-iscsi-2.0-865.9 on kernel-2.6.22. On bootup my root drive is /dev/sda and I have a flash drive on /dev/sdc. When I try to login to my iscsi device with mdadm I get a kernel oops: -bash# iscsiadm -m node -p 172.19.151.169:3260,1 -T iqn. 1999-02.com.nexsan:p0:sataboy:01731a5a --login Login session [iface: default, target: iqn. 1999-02.com.nexsan:p0:sataboy:01731a5a, portal: 172.19.151.169,3260] iscsi: cmd 0x35 is not queued (6) iscsi: cmd 0x35 is not queued (6) iscsi: cmd 0x35 is not queued (6) kobject_add failed for sdc with -EEXIST, don't try to register things with the same name in the same directory. BUG: unable to handle kernel NULL pointer dereference at virtual address 0008 printing eip: *pde = Oops: [#1] Modules linked in: iscsi_tcp libiscsi scsi_transport_iscsi CPU: 0 EIP: 0060:[c0189241] Not tainted VLI EFLAGS: 00210282 (2.6.22.10-vs2.2.0.5-cisco-nmx #1) EIP is at create_dir+0x21/0x190 eax: c226f584 ebx: f738bbd4 ecx: c226f588 edx: esi: c226f584 edi: c226f584 ebp: esp: f738bba4 ds: 007b es: 007b fs: gs: 0033 ss: 0068 Process iscsid (pid: 4461, ti=f738a000 task=f70dd0b0 task.ti=f738a000) Stack: c038d9b4 c038af10 c226f588 c226f584 c038af10 c0103c41 c226f584 c226f584 c226f584 c01893d4 f738bbd4
Kernel oops on login
Hey all, I'm running open-iscsi-2.0-865.9 on kernel-2.6.22. On bootup my root drive is /dev/sda and I have a flash drive on /dev/sdc. When I try to login to my iscsi device with mdadm I get a kernel oops: -bash# iscsiadm -m node -p 172.19.151.169:3260,1 -T iqn. 1999-02.com.nexsan:p0:sataboy:01731a5a --login Login session [iface: default, target: iqn. 1999-02.com.nexsan:p0:sataboy:01731a5a, portal: 172.19.151.169,3260] iscsi: cmd 0x35 is not queued (6) iscsi: cmd 0x35 is not queued (6) iscsi: cmd 0x35 is not queued (6) kobject_add failed for sdc with -EEXIST, don't try to register things with the same name in the same directory. BUG: unable to handle kernel NULL pointer dereference at virtual address 0008 printing eip: *pde = Oops: [#1] Modules linked in: iscsi_tcp libiscsi scsi_transport_iscsi CPU:0 EIP:0060:[c0189241]Not tainted VLI EFLAGS: 00210282 (2.6.22.10-vs2.2.0.5-cisco-nmx #1) EIP is at create_dir+0x21/0x190 eax: c226f584 ebx: f738bbd4 ecx: c226f588 edx: esi: c226f584 edi: c226f584 ebp: esp: f738bba4 ds: 007b es: 007b fs: gs: 0033 ss: 0068 Process iscsid (pid: 4461, ti=f738a000 task=f70dd0b0 task.ti=f738a000) Stack: c038d9b4 c038af10 c226f588 c226f584 c038af10 c0103c41 c226f584 c226f584 c226f584 c01893d4 f738bbd4 c0203a1f f79399c0 f737b840 c0186e80 f7939a10 f79399c0 c226f4c0 c226f584 f737b840 Call Trace: [c0103c41] dump_stack+0x11/0x20 [c01893d4] sysfs_create_dir+0x24/0x70 [c0203a1f] kobject_shadow_add+0x7f/0x1a0 [c0186e80] register_disk+0x50/0x1f0 [c01f4b72] blk_register_queue+0x52/0x90 [c026c6c8] sd_probe+0x278/0x3f0 [c0189e47] sysfs_create_link+0x57/0x150 [c0230c57] driver_probe_device+0x87/0x190 [c03461c1] klist_next+0x51/0xb0 [c022ff24] bus_for_each_drv+0x44/0x70 [c0230e19] device_attach+0x79/0x80 [c0230d60] __device_attach+0x0/0x10 [c022fe95] bus_attach_device+0x45/0x90 [c022eb93] device_add+0x493/0x560 [c0268502] scsi_sysfs_add_sdev+0x32/0x230 [c02665bd] scsi_probe_and_add_lun+0x95d/0x980 [c0266ada] __scsi_scan_target+0xda/0x5f0 [c01628ec] dput+0x1c/0xe0 [c01395de] filemap_nopage+0x23e/0x2e0 [c014296c] __handle_mm_fault+0x1fc/0x8d0 [c02676a6] scsi_scan_target+0xb6/0xe0 [f8a01760] iscsi_user_scan+0x70/0x90 [scsi_transport_iscsi] [f8a016f0] iscsi_user_scan+0x0/0x90 [scsi_transport_iscsi] [c026818b] store_scan+0xbb/0xf0 [c01107e0] do_page_fault+0x0/0x5e0 [c03482ca] error_code+0x6a/0x70 [c02680d0] store_scan+0x0/0xf0 [c0232196] class_device_attr_store+0x26/0x40 [c0188151] sysfs_write_file+0xb1/0x110 [c01880a0] sysfs_write_file+0x0/0x110 [c0153820] vfs_write+0xa0/0x140 [c0153da1] sys_write+0x41/0x70 [c010280e] sysenter_past_esp+0x5f/0x85 [c034] xdr_xcode_array2+0x3c0/0x5e0 === Code: 74 26 00 8d bc 27 00 00 00 00 83 ec 28 89 5c 24 18 8b 5c 24 2c 89 74 24 1c 89 7c 24 20 89 6c 24 24 89 d5 89 4c 24 08 89 44 24 0c 8b 42 08 83 c0 68 e8 94 e4 1b 00 31 c0b9 ff ff ff ff 8b 7c 24 EIP: [c0189241] create_dir+0x21/0x190 SS:ESP 0068:f738bba4 Feb 25 17:54:07 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 0008 Feb 25 17:54:07 localhost kernel: printing eip: Feb 25 17:54:07 localhost kernel: *pde = Feb 25 17:54:07 localhost kernel: Oops: [#1] Feb 25 17:54:07 localhost kernel: CPU:0 Feb 25 17:54:07 localhost kernel: EIP:0060:[c0189241]Not tainted VLI Feb 25 17:54:07 localhost kernel: EFLAGS: 00210282 (2.6.22.10- vs2.2.0.5-cisco-nmx #1) Feb 25 17:54:07 localhost kernel: EIP is at create_dir+0x21/0x190 Feb 25 17:54:07 localhost kernel: eax: c226f584 ebx: f738bbd4 ecx: c226f588 edx: Feb 25 17:54:07 localhost kernel: esi: c226f584 edi: c226f584 ebp: esp: f738bba4 Feb 25 17:54:07 localhost kernel: ds: 007b es: 007b fs: gs: 0033 ss: 0068 Feb 25 17:54:07 localhost kernel: Process iscsid (pid: 4461, ti=f738a000 task=f70dd0b0 task.ti=f738a000) Feb 25 17:54:07 localhost kernel: Stack: c038d9b4 c038af10 c226f588 c226f584 c038af10 c0103c41 c226f584 c226f584 Feb 25 17:54:07 localhost kernel:c226f584 c01893d4 f738bbd4 c0203a1f f79399c0 Feb 25 17:54:07 localhost kernel:f737b840 c0186e80 f7939a10 f79399c0 c226f4c0 c226f584 f737b840 Feb 25 17:54:07 localhost kernel: Call Trace: Feb 25 17:54:07 localhost kernel: [c0103c41] dump_stack+0x11/0x20 Feb 25 17:54:07 localhost kernel: [c01893d4] sysfs_create_dir +0x24/0x70 Feb 25 17:54:07 localhost kernel: [c0203a1f] kobject_shadow_add +0x7f/0x1a0 Feb 25 17:54:07 localhost kernel: [c0186e80] register_disk +0x50/0x1f0 Feb 25 17:54:07 localhost kernel: [c01f4b72] blk_register_queue +0x52/0x90 Feb 25 17:54:07 localhost kernel: [c026c6c8] sd_probe+0x278/0x3f0 Feb 25 17:54:07 localhost kernel: [c0189e47] sysfs_create_link +0x57/0x150 Feb 25 17:54:07 localhost kernel: [c0230c57] driver_probe_device +0x87/0x190 Feb 25 17:54:07
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?
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
-~--~~~~--~~--~--~---
Disconnected iSCSI and umount problems
I posted a little while back about this, but I still seem to be having trouble with this issue. Originally I tried to setup my iSCSI connection so that it had a 24 day timeout period and the no-op timers would be disabled. However this timeout led to a variety of issues including causing umount, reboot, and other commands to hang. So in the end the long timeout proved to be too much trouble so I moved back to the 120s timeout with noop timers enabled. However even this is causing me trouble. Currently I am using my iSCSI device to store video which means I am sending a large amount of data over the network into my device at a pretty high rate. In my tests if I cut the connection sometimes things will work out fine. The connection gets cut and after 120s I get a whole slew of iSCSI queuing errors and such and finally the iSCSI device gets remounted as read only. Once the error messages stop if I stop all of my video archiving, reconnect the iSCSI device, logout, umount the iSCSI, remount the iSCSI, log back in, and restart my video archiver everything will work fine. However in other cases when i cut the connection the iSCSI debugs won't be as numerous and it goes to read only mode almost immediately. When I try the above steps to recover my system hangs like before on the umount. I used KDB to get a dump of what is going during the umount and will add it to this message. It appears that the umount process has context switched out waiting for the io to complete. The io to be completed are 'sync'ing of the buffers which never happens or completed and does not wake up umount. I've tried numerous things to get around this umount issue including a variety of umount flags, the remount command, long delays in my code and the kernel code. But nothing has worked up to this point. I'm currently working on version 2.6.16 of the kernel with open iSCSI version 2.0-865.9. I am going to try the latest and greatest to see if that helps at all. I'm convinced that the current problem has something to do with a quick change to 'ro' mode vs a slower change to 'ro' mode after timeout. If you guys have any advice or insight I'd appreciate the help. I posted the debug in the files section. The filename is umount_hang.rtf. I've bolded the area where the umount gets called. Thanks. --~--~-~--~~~---~--~~ 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: umounting an iSCSI device with no connection
So I just tried issuing a logout with iscsiadm. After this I was able to umount and reboot no problem. Even though the iSCSI device can't respond does this command set something in the Kernel when it doesn't receive an ACK? -JD On Jun 2, 3:16 am, Tomasz Chmielewski [EMAIL PROTECTED] wrote: An Oneironaut schrieb: Hey all, So I'm having some problems using umount an my iSCSI device. I have my timeout period set to a really long time and the no-op timers have been switched off. If my system loses its connection to the iSCSI and I try to umount the device the command hangs. I've tried umount with the 'l' flag and the 'f' flag but neither have worked. And when I do this I am not able to kill the process even with kill -9. I've tried killing all the processes associate with the mount before umounting it. But nothing seems to work. Even when I try to reboot my system will hang requiring a hard reset. I've tried 'reboot -f' and 'reboot -n' but neither work. Has anyone run into this before or have any ideas how I can achieve either a umount or a successful reboot? Well, if you have a really long timeout and your connection is lost, umount and everything else will - not surprisingly - timeout with the period you specified. Your solutions are: - restore the connection - if possible, try to decrease the timeout just before loosing the connection - if the connection is lost already, you may also try to decrease the timeout, but I'm not sure it'll work, - don't shut your network interfaces down when rebooting or halting the system (distro-specific; for Debian, look into /etc/init.d/halt and NETDOWN / $netdown; others may use $HALTARGS variable in /etc/init.d/halt etc.). An example for setting the timeout to 120 seconds: iscsiadm -m node -T iqn.2007-05.net.my:store.backup -o update -n node.session.timeo.replacement_timeout -v 120 -- 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 -~--~~~~--~~--~--~---
umounting an iSCSI device with no connection
Hey all, So I'm having some problems using umount an my iSCSI device. I have my timeout period set to a really long time and the no-op timers have been switched off. If my system loses its connection to the iSCSI and I try to umount the device the command hangs. I've tried umount with the 'l' flag and the 'f' flag but neither have worked. And when I do this I am not able to kill the process even with kill -9. I've tried killing all the processes associate with the mount before umounting it. But nothing seems to work. Even when I try to reboot my system will hang requiring a hard reset. I've tried 'reboot -f' and 'reboot -n' but neither work. Has anyone run into this before or have any ideas how I can achieve either a umount or a successful reboot? I'm running on the 2.6.16 kernel which I don't want to change. I saw this problem on google in relation to NFS but no solution that I could find. I'd appreciate any help. Thanks, Anon --~--~-~--~~~---~--~~ 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: iSCSI Timeout
Hey Mike, I accidentally deleted my log so I can't give you anymore :-\. But the error (1011) is there in the dump I sent. I also have timed the error and it looks like it takes about 20 to 21 seconds. I have also found a work around. I changed my timeout time to 14 Days(1209600s) and the timeout seems to be working now. Hope this helps. -JD On May 14, 9:11 am, Mike Christie [EMAIL PROTECTED] wrote: An Oneironaut wrote: I gave this a try but now when I set the timeout for a really long period and disconnect my iSCSI device to test it, after about 2 minutes I get this: 28May 13 13:15:48 localhost iscsid: Kernel reported iSCSI connection 4:0 error (1011) state (3) 31May 13 13:15:48 localhost iscsid: re-opening session 4 (reopen_cnt 1) 31May 13 13:15:48 localhost iscsid: thread 0807e1cc delete: state 2 31May 13 13:15:48 localhost iscsid: in kstop_conn 31May 13 13:15:48 localhost iscsid: in __kipc_call 31May 13 13:15:48 localhost iscsid: in kwritev 6May 13 13:15:59 localhost kernel: session4: iscsi: session recovery timed out after 2678400 secs Could you send the part of the log where the error is detected (it would say something about iscsi connection error (1011)), so we know the timing better? 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: SCSI error: return code = 0x2 4May 13 13:15:59 localhost kernel: end_request: I/O error, dev sdb, sector 75752 3May 13 13:15:59 localhost kernel: Buffer I/O error on device sdb, logical block 9469 4May 13 13:15:59 localhost kernel: lost page write due to I/O error on sdb I am using an older version of open iscsi, Version 2.0-865.9. Is this why I am losing the connection before the time out period? I do not think so. It looks like a bug in the timer setting. It looks like the iscsi layer has the right value (you wanted 2678400 right?), but the timer layer may not be handling rollover correctly. Could you possibly try a newer kernel just for testing? 2.6.16 is really old and has other bugs. I will try this out on a current kernel and 2.6.16 to see if I can replicate. --~--~-~--~~~---~--~~ 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: iSCSI Timeout
Btw I'm running on 2.6.16 and I'm just trying to set things up so that if my iscsi goes down the timeout will be long enough for the device to be connected within 24 hours and start working again. On May 13, 3:31 pm, An Oneironaut [EMAIL PROTECTED] wrote: I gave this a try but now when I set the timeout for a really long period and disconnect my iSCSI device to test it, after about 2 minutes I get this: 28May 13 13:15:48 localhost iscsid: Kernel reported iSCSI connection 4:0 error (1011) state (3) 31May 13 13:15:48 localhost iscsid: re-opening session 4 (reopen_cnt 1) 31May 13 13:15:48 localhost iscsid: thread 0807e1cc delete: state 2 31May 13 13:15:48 localhost iscsid: in kstop_conn 31May 13 13:15:48 localhost iscsid: in __kipc_call 31May 13 13:15:48 localhost iscsid: in kwritev 6May 13 13:15:59 localhost kernel: session4: iscsi: session recovery timed out after 2678400 secs 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: scsi: Device offlined - not ready after error recovery 6May 13 13:15:59 localhost kernel: sd 4:0:0:0: SCSI error: return code = 0x2 4May 13 13:15:59 localhost kernel: end_request: I/O error, dev sdb, sector 75752 3May 13 13:15:59 localhost kernel: Buffer I/O error on device sdb, logical block 9469 4May 13 13:15:59 localhost kernel: lost page write due to I/O error on sdb I am using an older version of open iscsi, Version 2.0-865.9. Is this why I am losing the connection before the time out period? -Anon On May 9, 7:55 am, Mike Christie [EMAIL PROTECTED] wrote: An Oneironaut wrote: Are there any issues with getting rid of the iSCSI timeout? I would like my initiator to continually try to find the target device until it comes back up. I've only got one Linux System and one ISCSI device so there aren't any multi-device issues here. Thoughts? Yeah, you can turn up replacement timeout very high and turn off the nop timers if you wanted to. See the README. If you have multiple portals on the target though you probably just want to use dm-multipath with iscsi and set queue_if_no_path or no_path_retry queue in the mutlipath.conf file. --~--~-~--~~~---~--~~ 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 Timeout
Are there any issues with getting rid of the iSCSI timeout? I would like my initiator to continually try to find the target device until it comes back up. I've only got one Linux System and one ISCSI device so there aren't any multi-device issues here. Thoughts? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
