Re: Should connection restored?
I changed timeout as follows. 1. iscsiadm --mode discovery --type sendtargets --portal 192.168.7.174 2. iscsiadm -m node -T iqn.2008-05.com.abcde:Tar1 -p 192.168.7.174:3260 --login 3. iscsiadm -m node -T iqn.2008-05.com.qualexsystems:Tar1 -p 192.168.7.174:3260 -o update -n node.session.timeo.replacement_timeout -v 82400 (got succedded) 4. I mounted disk exposed and started some i/o on it. 5. Then i restarted iscsi-target daemon output of dmesg after during step 4 - __journal_remove_journal_head: freeing b_frozen_data scsi 1:0:0:1: rejecting I/O to dead device Buffer I/O error on device sdh1, logical block 529 lost page write due to I/O error on sdh1 scsi2 : iSCSI Initiator over TCP/IP Vendor: IET Model: VIRTUAL-DISK Rev: 0 Type: Direct-Access ANSI SCSI revision: 04 SCSI device sdg: 630784 512-byte hdwr sectors (323 MB) sdg: Write Protect is off sdg: Mode Sense: 77 00 00 08 SCSI device sdg: drive cache: write through SCSI device sdg: 630784 512-byte hdwr sectors (323 MB) sdg: Write Protect is off sdg: Mode Sense: 77 00 00 08 SCSI device sdg: drive cache: write through sdg: sdg1 sd 2:0:0:0: Attached scsi disk sdg sd 2:0:0:0: Attached scsi generic sg6 type 0 Vendor: IET Model: VIRTUAL-DISK Rev: 0 Type: Direct-Access ANSI SCSI revision: 04 SCSI device sdh: 630784 512-byte hdwr sectors (323 MB) sdh: Write Protect is off sdh: Mode Sense: 77 00 00 08 SCSI device sdh: drive cache: write through SCSI device sdh: 630784 512-byte hdwr sectors (323 MB) sdh: Write Protect is off sdh: Mode Sense: 77 00 00 08 SCSI device sdh: drive cache: write through sdh: sdh1 sd 2:0:0:1: Attached scsi disk sdh sd 2:0:0:1: Attached scsi generic sg7 type 0 kjournald starting. Commit interval 5 seconds EXT3 FS on sdh1, internal journal EXT3-fs: mounted filesystem with ordered data mode. dmesg after step 5 session1: iscsi: session recovery timed out after 120 secs iscsi: cmd 0x2a is not queued (7) sd 2:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdh, sector 390208 Buffer I/O error on device sdh1, logical block 195073 lost page write due to I/O error on sdh1 Buffer I/O error on device sdh1, logical block 195074 lost page write due to I/O error on sdh1 Aborting journal on device sdh1. iscsi: cmd 0x2a is not queued (7) sd 2:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdh, sector 390208 Buffer I/O error on device sdh1, logical block 195073 lost page write due to I/O error on sdh1 Buffer I/O error on device sdh1, logical block 195074 lost page write due to I/O error on sdh1 __journal_remove_journal_head: freeing b_committed_data ext3_abort called. EXT3-fs error (device sdh1): ext3_journal_start_sb: Detected aborted journal Remounting filesystem read-only iscsi: cmd 0x2a is not queued (7) sd 2:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdh, sector 66 Buffer I/O error on device sdh1, logical block 2 lost page write due to I/O error on sdh1 iscsi: cmd 0x2a is not queued (7) iscsi: cmd 0x2a is not queued (7) sd 2:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdh, sector 376896 Buffer I/O error on device sdh1, logical block 188417 lost page write due to I/O error on sdh1 sd 2:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdh, sector 376900 Buffer I/O error on device sdh1, logical block 188419 lost page write due to I/O error on sdh1 --- What is exactly happening here? timeout value is changing from 120 to 86400..How can i re-confirm that? Can there be some other problem as well? - Target: iqn.2008-05.com.qualexsystems:Tar2 Current Portal: 192.168.7.174:3260,1 Persistent Portal: 192.168.7.174:3260,1 ** Interface: ** Iface Name: default Iface Transport: tcp Iface IPaddress: default Iface HWaddress: default Iface Netdev: default SID: 4 iSCSI Connection State: LOGGED IN Internal iscsid Session State: NO CHANGE Negotiated iSCSI params: HeaderDigest: CRC32C DataDigest: None MaxRecvDataSegmentLength: 131072 MaxXmitDataSegmentLength: 8192 FirstBurstLength: 65536 MaxBurstLength: 262144 ImmediateData: No InitialR2T: Yes MaxOutstandingR2T: 1
Re: System hanging with MD3000i with Debian Etch
On Sun, May 18, 2008 at 06:21:17PM -0700, Bryan Mclellan wrote: Of the linux servers console? Sure I can dig one up, it's the first two lines of the scsi disk sort of display, twice. Something sort of like: Preferably the whole thing from start. Not just the last X lines. Disk: DELL Model: MD3000 Blah blah blah blah I don't recall exactly what it said, but it wasn't very interesting. It is for kernel engineers. Also please pass in as bootup parameter this value 'loglevel=8'. --~--~-~--~~~---~--~~ 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: Maximum LUN support
Hi all,
Further update on this topic:
Thanks once again :) - If I manage to find/assert it, I will surely
post back.
I tried to do an experiment to confirm the maximum number of available
targets and LUNs with an initiator. I did:
On the target machine:
1. I created softlinks for a device such that they are named /dev/link
$i_$j where i varies from 1-100 and j varies from 0-10. Thus, I had
links like link1_0, link1_1, ...,link30_0,...,
link99_0, ...link100_10.
2. Each link was a softlink of a valid SCSI device on the target. All
this was pushed into the /etc/ietd.conf file and service iscsi-target
was restarted. (Yup, I am using iscsi-target-0.4.16 on the target
side.)
3. This gave me 100 targets, each having 10 LUNs - starting from
mydisk1 to mydisk100 (as target names).
On the initiator:
1. I set the discovery on this target machine IP. and tried to log in.
result:
Discovery itself is not able to add more than 89 (twice I got 90)
devices. It simply doesn't get any information about the top 11
devices from the ietd.conf file.
On the target, the message log contained something like Dropping key
(target ___ ) which, I found, was appearing from text_key_add()
function from the iscsi-target package.
The code is something like:
...
if (conn-rsp.datasize + len INCOMING_BUFSIZE) {
log_warning(Dropping key (%s=%s), key, value);
return;
}
...
Initiator doesn't show any error, and infact the node list (iscsiadm -
m node) doesn't display any device starting from mydevice1 -
mydevice11 in the list.
I tried this experiment many times by
1. changing the number of LUNs,
2. changing the device being pointed to by the soft links,
3. changing the number of target devices defined in ietd,
4. making half the links point to one device, and other half to other
5. Shuffling the order of ietd defined target names (and each time
starting 10-11, according to definition in ietd.conf, are not send by
target, whatever there name be).
Each time the result was same (atleast) - 89-90 can only be added.
I am still trying to find what could be the possible bottleneck that
is preventing me to add more devices - till then, I would really
appreciate if there is anything anyone would like to point out. Any
hints or mistakes I am making? Hopefully, using dummy (links) is not
something not-allowed as per target/initiator implementation.
--
Shreyansh
--~--~-~--~~~---~--~~
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: target*/*/block:change
Stefan de Konink wrote: What was the reason for adding the block device name to the block symlink if this symlink already provides this name? iscsi has not control over the block device naming and symlinks. You would want to ask lkml. It probably breaks everything that uses this block path directly to find out the device it is pointing to. I am not sure if that is a good idea. There is a doc that comes with the kernel on how to write for sysfs. I attached it here. The iscsi sysfs code does not follow this and that is why it got busted when sysfs compat is disbaled in the kernel. I am replacing our sysfs code right now though. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- Rules on how to access information in the Linux kernel sysfs The kernel-exported sysfs exports internal kernel implementation details and depends on internal kernel structures and layout. It is agreed upon by the kernel developers that the Linux kernel does not provide a stable internal API. As sysfs is a direct export of kernel internal structures, the sysfs interface cannot provide a stable interface either; it may always change along with internal kernel changes. To minimize the risk of breaking users of sysfs, which are in most cases low-level userspace applications, with a new kernel release, the users of sysfs must follow some rules to use an as-abstract-as-possible way to access this filesystem. The current udev and HAL programs already implement this and users are encouraged to plug, if possible, into the abstractions these programs provide instead of accessing sysfs directly. But if you really do want or need to access sysfs directly, please follow the following rules and then your programs should work with future versions of the sysfs interface. - Do not use libsysfs It makes assumptions about sysfs which are not true. Its API does not offer any abstraction, it exposes all the kernel driver-core implementation details in its own API. Therefore it is not better than reading directories and opening the files yourself. Also, it is not actively maintained, in the sense of reflecting the current kernel development. The goal of providing a stable interface to sysfs has failed; it causes more problems than it solves. It violates many of the rules in this document. - sysfs is always at /sys Parsing /proc/mounts is a waste of time. Other mount points are a system configuration bug you should not try to solve. For test cases, possibly support a SYSFS_PATH environment variable to overwrite the application's behavior, but never try to search for sysfs. Never try to mount it, if you are not an early boot script. - devices are only devices There is no such thing like class-, bus-, physical devices, interfaces, and such that you can rely on in userspace. Everything is just simply a device. Class-, bus-, physical, ... types are just kernel implementation details which should not be expected by applications that look for devices in sysfs. The properties of a device are: o devpath (/devices/pci:00/:00:1d.1/usb2/2-2/2-2:1.0) - identical to the DEVPATH value in the event sent from the kernel at device creation and removal - the unique key to the device at that point in time - the kernel's path to the device directory without the leading /sys, and always starting with with a slash - all elements of a devpath must be real directories. Symlinks pointing to /sys/devices must always be resolved to their real target and the target path must be used to access the device. That way the devpath to the device matches the devpath of the kernel used at event time. - using or exposing symlink values as elements in a devpath string is a bug in the application o kernel name (sda, tty, :00:1f.2, ...) - a directory name, identical to the last element of the devpath - applications need to handle spaces and characters like '!' in the name o subsystem (block, tty, pci, ...) - simple string, never a path or a link - retrieved by reading the subsystem-link and using only the last element of the target path o driver (tg3, ata_piix, uhci_hcd) - a simple string, which may contain spaces, never a path or a link - it is retrieved by reading the driver-link and using only the last element of the target path - devices which do not have driver-link just do not have a driver; copying the driver value in a child device context is a bug in the application
Re: Maximum LUN support
Shrey wrote: Hi all, Further update on this topic: Thanks once again :) - If I manage to find/assert it, I will surely post back. I tried to do an experiment to confirm the maximum number of available targets and LUNs with an initiator. I did: On the target machine: 1. I created softlinks for a device such that they are named /dev/link $i_$j where i varies from 1-100 and j varies from 0-10. Thus, I had links like link1_0, link1_1, ...,link30_0,..., link99_0, ...link100_10. 2. Each link was a softlink of a valid SCSI device on the target. All this was pushed into the /etc/ietd.conf file and service iscsi-target was restarted. (Yup, I am using iscsi-target-0.4.16 on the target side.) 3. This gave me 100 targets, each having 10 LUNs - starting from mydisk1 to mydisk100 (as target names). On the initiator: 1. I set the discovery on this target machine IP. and tried to log in. result: Discovery itself is not able to add more than 89 (twice I got 90) devices. It simply doesn't get any information about the top 11 devices from the ietd.conf file. When you say devices, you mean targets right? open-iscsi-2.0-869 should work. I believe iscsi-target-0.4.16 does not support lots of targets. You shuold post to the IET list. I think there are threads on this already, so actually you should search their list to make sure it is not fixed in the svn tree. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
