Multiple login BUG to same targets in Fedora 19
Hi iscsi guys I have an annoying problem on Fedora 19. Though it must be a problem on Fedora + new systemd I think it also exposes a bug in iscsiadm and/or Kernel login system. I have a target system that uses tgtd to export multiple targets from the same IP address. Note that this is multiple targets from same tgtd instance and not multiple LUNs of the same target. Now when I first run iscsiadm -m discovery -t sendtargets -p $TARGET_IP --login All is well and I get my 8 targets as expect. But ... After reboot I get each target multiple times. On a VM Machine I get each target 3 times on a Notebook machine I get them twice. This behavior is not observed on Fedora 18. Now from prints it looks like the new systemd iscsi service tries a login for each target which is good if each target has it's own IP, but apparently fails here. But what I do not understand is how the iscsiadm lets multiple logins to the same exact target+initiator combination? Is this a bug in the bootup system, because manually running iscsiadm does not let you do this? Also if memory serves me correctly before iscsiadm used to complain about refusing to login multiple times. With new version it does not complain at all, and only re-logins into the targets. Which is interesting BTW, on the machine that shows the problem above with multiple devices of the same target. Once I run iscsiadm -m discovery -t sendtargets again, manually, the 16 or 24 devices that were there before disappear and the proper unique 8 re-appear. So, is that a Fedora bug or an iscsid bug? I will be glad to provide any logs and tests you might need. If you guys do not have Fedora 19. (I will also try to open a Fedora bug, see how that's done) Thanks Boaz -- 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: Multiple login BUG to same targets in Fedora 19
On 12/06/2013 01:18 AM, Mike Christie wrote: On 12/05/2013 05:43 AM, Boaz Harrosh wrote: Hi iscsi guys But what I do not understand is how the iscsiadm lets multiple logins to the same exact target+initiator combination? Is this a bug in the bootup system, because manually running iscsiadm does not let you do this? You can manually create multiple sessions by running the iscsiadm -m session -r id -o new Mike hi. I never played with multiple sessions but surly it does not look like the case here. And I do not understand. would a new sessions create a new SCSI device (a new /dev/bsg/X:0:0:0). I understood that it would be the same device. But Ye I guess you are right to the system it would look like a new device I guess I never thought about that. But do you think the start up code would mess with -m session -o new? why would it do that? and again the problem is only when you have multiple target from same IP machine. (And also with the multiple sessions thing, does the target need to support it as well? I mean does tgtd supports it without any extra configuration? ) command or by setting node.nr_sessions 1. By default upstream does not do this. Also if memory serves me correctly before iscsiadm used to complain about refusing to login multiple times. With new version it does not complain at all, and only re-logins It should still do this. It does with the code in git if nr_sessions is 1. What do you mean by relogin? Does it create a new session or force the existing session to relogin? I'm not sure, I did not dig into this. All I know is that at first I have 24 devices (ls /dev/bsg/* 0:0:0:0 - 23:0:0:0) and after manual issue of iscsiadm -m discovery -t sendtargets I get only 8 of them. So something has logged out of the other devices right? I will do a -d 8 from iscsiadm and see if I can figure if it is a create a new session or existing session to relogin (I'll send you the logs) It might have something to do with iscsid + systemd. I only tested oracle linux 6.4 with the git code. I cc'd Chris Leech. I think he handles iscsi in fedora. Send the logs. I will install fedora 19 when I get some time here. Do you know how to produce log prints from the iscsi bootup systemd code? I mean manually everything is fine. Only the bootup code does the wrong thing. in dmesg it all looks like the system scanned for 16-24 scsi devices. But there is no special prints I can see. On the systemd output to console I see that it has attempted 8 separate logins, for each entry in the DB. But we know that a single login would have produced the 8 needed devices and all the other attempts would return already exist. Then the big question why only 2 or 3 produce a new set of devices and the other do not. Because in my math we should have then seen 8 * 8 devices, no? Thanks Boaz -- 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: Multiple login BUG to same targets in Fedora 19
On 12/06/2013 01:51 AM, Chris Leech wrote: On Thu, Dec 05, 2013 at 05:18:35PM -0600, Mike Christie wrote: On 12/05/2013 05:43 AM, Boaz Harrosh wrote: Hi iscsi guys into the targets. Which is interesting BTW, on the machine that shows the problem above with multiple devices of the same target. Once I run iscsiadm -m discovery -t sendtargets again, manually, the 16 or 24 devices that were there before disappear and the proper unique 8 re-appear. So, is that a Fedora bug or an iscsid bug? It might have something to do with iscsid + systemd. I only tested oracle linux 6.4 with the git code. I think this is a problem with the systemd unit files and the network manager dispatcher script in the fedora package. I ran into a similar problem and made some changes for fedora 20, but haven't pushed an update for 19. If the issue is what I think it is, then as multiple network interfaces come online the network manager script keeps trying to check for auto-start iscsi sessions that need to be retried. It ends up with multiple copies of iscsiadm running at the same time, all asking iscsid to create new sessions to the same target portals. I'll get a f19 update package ready for you to try, if that's OK? Yes I would love that thanks! Yes that would explain why one system has 8 * 2 and the second 8 * 3 the nick count match. But this brings out a new question. If iscsiadm is ran in parallel is it not a bug to let in wrong handling. Should we not serialize operations so that the other instances fail were they would normally fail if they ran in series? Mike? - Chris Thanks Chris. Boaz -- 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: Automatic deleting of LUNs possible?
On 10/31/2012 10:32 PM, Michael Christie wrote: On Oct 30, 2012, at 7:31 PM, amit.ut...@gmail.com wrote: I apologize if this has been asked in the list before, I did some research but did not find a clear answer/recommendation. Currently, I use udev to monitor new devices added by the open-iscsi initiator. This works great. However, when the target is disconnected I get timeout messages in the kernel log but the device nodes in /dev/ still exists. Thus, no udev events. As noted in a few of the messages in the archives, doing a rescan does not automatically delete the LUNs. So the following script was suggested: scsi_sz=`sg_readcap /dev/sdko | grep address | sed s'/.*blocks=//'` kernel_sz=`cat /sys/block/sdko/device/block\:sdko/size` if (($scsi_sz==$kernel_sz)); then echo Good. else echo Do the deletion of the block device. echo 1 /sys/block/sdko/device/delete fi This looks like it will do the trick. But I am wondering if this is still the recommended approach as the above suggestion was made in 2008. I do not know about recommended, but it will work, and we have not implemented something like dev_loss_tmo FC behavior so it is one of the only options. Mike hi Did we ever consider integrating iscsi with the hotplug infrastructure? It could be nice if an admin could specify at configuration time if he wants the device permanently attached but offline on error like today, or if he wants an hot-unplug notification like a usb device. Thanks Boaz -- 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: Automatic deleting of LUNs possible?
On 11/02/2012 12:47 PM, Mike Christie wrote: Yeah, I updated the iscsi dev loss tmo patch and posted it to the list. I think I hit some bugs with lots of sessions and lots of removals at the same time due to some workqueue/threading stuff or scsi locking issues. I did not get a chance to look into more. Before reposting I wanted to make the dev loss code generic and hook all transport into it since srp and sas wanted it too. Ha nice so you are already working on it? Nice that could come handy. Do you have some documentation on it? like what timeout/configuration controls when dev loss is triggered. Will it be a PM hot-unplug event or do we need new udev rules for it? Thanks Boaz -- 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: Error codes/return values of iscsiadm commands
On 07/14/2010 08:23 PM, Mike Christie wrote:
On 07/14/2010 10:49 AM, Boaz Harrosh wrote:
On 07/14/2010 05:52 PM, Mike Christie wrote:
On 07/14/2010 05:30 AM, HIMANSHU wrote:
How can we know error status of iscsiadm commands like
discovery,login,logout.
I think,all of them directly returns corresponding success/failure
messages.
so mostly I can just fire the commands without checking any error
codes after it?
If you run
iscsiadm -m node -l
iscsiadm should return a error code like other programs. If you wanted
to see it you could do
iscsiadm -m node -l
echo $?
Speaking of which. When I want to completely run from a script file
I currently have two ugly loops
after starting the iscsi service and before I can iscsiadm I must do:
start_iscsi_intiator()
{
if ! service $ISCSI status; then
service iscsi start ;
until cat /sys/class/iscsi_transport/tcp/handle 2/dev/null ; do
sleep 1;
done
fi
}
Effectively wait for the /sys/class/iscsi_transport/tcp/handle file to appear
And after login but before I can actually start banging on my scsi device I
need:
login_iscsi()
{
echo login into: $IP_ISCSI
$iscsiadm -m discovery -t sendtargets -p $IP_ISCSI --login;
until ls $DEV_ISCSI 2/dev/null; do sleep 1; done
}
Effectively wait for the device to appear. This one is particularly nasty
because it assumes that I know what $DEV_ISCSI will be.
Would we want to add a --wait-server and --wait switches to iscsiadm
--wait-server- will wait for the iscsi-kernel-modules and iscsid
server
to stabilize. (until some timeout)
Not sure. When service iscsi start is run, it will eventually load the
modules. The script does not return until modprobe has returned and
modprobe does not return until the kernel module module_init function
and those do not return until it has run the sysfs functions that create
the files you are waiting on. So are you saying that once module_init
has completed the files are not accessible right away?
OK, so I just got lucky here probably, since I'm doing a sleep 1;
so the first iteration fails then a 1 sec wait is good enough. I think
what happens is that the iscsid server is not yet ready for communication
with iscsiadm. I'll remove the wait and run with debug-on see what actually
fails.
--wait - with a --login will wait (with timeout) until the
loggedin
device is available.
For this one, the --login command returns once the scsi kernel scan is
completed (the tools just do write(/sys/class/scsi_host/hostX/scan). So
the kernel inquiries and report luns and scsi_device struct stuff is
done, and the kernel has sent hotplug events to notify userspace. So the
problem you are hitting is that things like udev have not handled the
hotplug event and created the /dev links right?
We could just add a wait in iscsiadm or the iscsi init scripts for this.
It would basically do
iscsiadm -m ... --login
iscsiadm -m session -P 3 | grep some_string_to_get_devices
wait on each device
Yes something like this, which is what I do. Perhaps just give
an example script with the recommended way to do it. (or add the --wait)
init scripts with auto-login work fine. It's only if I run the complete
lot from script as above .ie
start_iscsi_intiator
login_iscsi
mount_dev
Then I need these two waits above. otherwise it fails.
It's not urgent just if you can think about it a bit
Thanks
Boaz
--
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 performance via 10 Gig
On 05/26/2010 09:52 PM, Vladislav Bolkhovitin wrote: Boaz Harrosh, on 05/26/2010 10:45 PM wrote: On 05/26/2010 09:42 PM, Vladislav Bolkhovitin wrote: Taylor, on 05/26/2010 09:32 PM wrote: I'm curious what kind of performance numbers people can get from their iscsi setup, specifically via 10 Gig. We are running with Linux servers connected to Dell Equallogic 10 Gig arrays on Suse. Recently we were running under SLES 11, and with multipath were seeing about 2.5 Gig per NIC, or 5.0 Gbit/sec total IO throughput, but we were getting a large number of iscsi connection errors. We are using 10 Gig NICs with jumbo frames. We reimaged the server to OpenSuse, same hardware and configs otherwise, and since then we are getting about half, or 1.2 to 1.3 Gbit per NIC, or 2.5 to 3.0 Gbit total IO throughput, but we've not had any iscsi connection errors. What are other people seeing? Doesn't need to be an equallogic, just any 10 Gig connection to an iscsi array and single host throughput numbers. ISCSI-SCST/open-iscsi on a decent hardware can fully saturate 10GbE link. On writes even with a single stream, i.e. something like a single dd writing data to a single device. Off topic question: That's a fast disk. A sata HD? the best I got for single sata was like 90 MB/s. Did you mean a RAM device of sorts. The single stream data were both from a SAS RAID and RAMFS. The multi-stream data were from RAMFS, because I don't have any reports about any tests of iSCSI-SCST on fast enough SSDs. Right thanks. So the SAS RAID had what? like 12-15 spindles? Vlad Boaz -- 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 1/2] RFC: Proposal for BSG Interface
On 03/17/2010 08:06 PM, Jayamohan Kallickal wrote: This patch contains the bsg interface based on the bsg interface in FC. What? where? who? how? why? w*\? ... You are proposing a new Kernel ABI/API here right. I think it is not acceptable without a detailed documentation, including every little bit. Nothing missing. If lots of it is already written for FC then grate most of your job is done. But for us mortals please put some text on an introductory message. I use iscsi everyday for 4 years, your mail should answer the question: what am I missing? Developed and submitted earlier by James Smart. Signed-off-by: James Smart james.sm...@emulex.com Signed-off-by: Jayamohan Kallickal jayamoh...@serverengines.com Boaz -- 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: Can I tell if my iSCSI is already mounted somewhere else?
On 02/24/2010 09:14 AM, guymatz wrote: Hello, I would really love to be able to tell if (and ideally where!) an iSCSI LUN (right word here?) is mounted. I don't want to mount it twice . . ! Any way to do this? Is there an ideal way to do iSCSI accounting? Thanks a lot, Guy once you mount your LUN identify it in /dev/disk/by-id/* from then on it will stay the same no matter whet /dev/sd* it is. You can specify /dev/disk/by-id/ everywhere, like in fstab and not care about what letter it has. If your lun is not mounted you will not find it in /dev/disk/by-id/ (If the LUN has a filesystem on it it will also be in /dev/disk/by-uuid/* ) Good luck Boaz -- 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: How to make a 2.6..*_compat.patch without sub-directory?
On 12/14/2009 08:25 PM, Yangkook Kim wrote: I posted similar message on other thread, but let me ask the same question with diffrent tittle. I want to make a kernel compat patch without kernel/ sub-directory. I used git diff to output the patch, but each header of outputted patch includes kernel/ sub-directory like below. e.g diff --git a/kernel/libiscsi.c b/kernel/libiscsi.c index 0b810b6..6ffb49c 100644 --- a/kernel/libiscsi.c +++ b/kernel/libiscsi.c git history shows me that other people have made a compat patch without kernel/ sub-directory in headers. Can anybody tell me how to do this? Thanks, Kim Please don't do that please submit a patch to Makefile so it can accept either formats. Boaz -- 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: Unable to apply kernel/2.6.26_compat.patch from git master branch
On 12/08/2009 09:15 PM, Yangkook Kim wrote: Hi, you are back. I think for your patch, you want to include open_iscsi_compat.h in it. I included open_iscsi_compat.h and created a patch. Please check it. I have a quetion about creating a patch agaist files in sub-directory. I used git diff to output the patch, but each hunk of outputted patch includes kernel/ sub-directory. e.g diff --git a/kernel/libiscsi.c b/kernel/libiscsi.c index 0b810b6..6ffb49c 100644 --- a/kernel/libiscsi.c +++ b/kernel/libiscsi.c However, kernel/ sub-directory in the compat patch will prevent you from making and your current compat patch is actually does't have kernel/ sub-directory. e.g diff --git a/libiscsi.c b/libiscsi.c index 149d5eb..467abbf 100644 --- a/libiscsi.c +++ b/libiscsi.c How do I make a patch without the sub-directory? Since I didn't know how to do it, I simply remove the sub-directory by,,, sed -i 's%a\/kernel%a%g' update_2.6.26_compat.patch2 sed -i 's%b\/kernel%b%g' update_2.6.26_compat.patch2 But, this obviously isn't the way to do it...It will be very appriciated if you tell me the right way to do it. Thanks. At the time I wrote the patching in Makefile we were using svn. I even included instructions on how to generate the patch file for submission. Now when we are using git, the procedure should be fixed. I think all you have to do is put a -p0 on the patch command line (In Makefile). Please experiment with it and send a patch to fix the Makefile. (Do you need that I do it? Just that I haven't checked out a tree for a year) Boaz -- 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] Fix compilation warnings in usr/kernel code
On 09/03/2009 08:02 PM, Mike Christie wrote: On 09/03/2009 11:21 AM, Erez Zilber wrote: Fix compilation warnings and modify the Makefiles to treat warnings as errors. Signed-off-by: Erez Zilber erezzi.l...@gmail.com Thanks. I get this compilation error on fedora 10. We used to get a warning about it not being initialized and upstream we did this patch. Is this just a bug in my compiler? @@ -693,6 +692,7 @@ int iscsi_add_session(struct iscsi_cls_session *session, unsigned int target_id) Too many iscsi targets. Max number of targets is %d.\n, ISCSI_MAX_TARGET - 1); + err = -EOVERFLOW; Better use the uninitialized_var() macro on declaration of variable. 1. It does not produce any code in shutting up the warning. 2. There is a scrip laying around that turns the macro off and looks for warning instances for every uninitialized_var use. So in the future this can be removed when the compilers we care about stop to complain. 3. Better Programmer's communication of what's up. Boaz goto release_host; } } make make -C /lib/modules/2.6.29.4-167.fc11.x86_64/build M=`pwd` KBUILD_OUTPUT= V=0 modules make[1]: Entering directory `/usr/src/kernels/2.6.29.4-167.fc11.x86_64' CC [M] /home/mnc/kernel/iscsi/open-iscsi/devel/open-iscsi/kernel/scsi_transport_iscsi.o cc1: warnings being treated as errors /home/mnc/kernel/iscsi/open-iscsi/devel/open-iscsi/kernel/scsi_transport_iscsi.c: In function ‘iscsi_add_session’: /home/mnc/kernel/iscsi/open-iscsi/devel/open-iscsi/kernel/scsi_transport_iscsi.c:678: error: ‘err’ may be used uninitialized in this function make[2]: *** [/home/mnc/kernel/iscsi/open-iscsi/devel/open-iscsi/kernel/scsi_transport_iscsi.o] Error 1 make[1]: *** [_module_/home/mnc/kernel/iscsi/open-iscsi/devel/open-iscsi/kernel] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.29.4-167.fc11.x86_64' --~--~-~--~~~---~--~~ 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: same volume two different hosts
On Fri, Jul 31, 2009 at 7:12 PM, nick nicholasfredd...@gmail.com mailto:nicholasfredd...@gmail.com wrote: Hi All, I would like to knw if i can present same volume to two hosts? I am using Stonefly Voyager as SAN and the host would be Xen. Thanks in Advance Nick On 08/03/2009 11:30 PM, Donald Williams wrote: Hello Nick, While an iSCSI SAN will not have any problem allowing multiple hosts to connect to the same volume, what it doesn't do is protect you from the resultant corruption. Each host will believe it owns that volume exclusively. Writes from one host won't be seen by the other host. They will eventually overwrite blocks written by the other and corrupt the file allocation table. The solution is to use a global or clustering fllesystem that will manage the cache and writes. Filesystems like GFS, Polyserve, IBRIX, Tivoli, etc... GFS is open source, the others are commercial filesystems that run many thousands of dollars. -don In modern Kernels it's called GFS2 OCFS2 is also a cluster filesystem I think Boaz --~--~-~--~~~---~--~~ 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] libiscsi: Check for CmdSN window before sending data
On 07/23/2009 12:24 PM, Mike Christie wrote: But you still might be hitting a problem where the target does not like data-outs when it closed the window. Maybe they interpreted the RFC differently. You should ask the HP target guys for more info. Also your patch might be working because I think it ends up throttling the connection, so IO does not timeout because pipes are backed up (the slow down from the throttling is one of the problems we hit with the patch I did before which was pretty much the same as you posted). I think that what Hannes patch is doing is exactly that off-by-one command. So maybe you are right and it is an HP bug where the window check is off-by-one or they do not like data-outs after window close. Try to compare less-one in queuecommand and see if it helps the same? I think I can replicate this problem now too. It was by accident. I am using a EQL target remotely (I am in the middle of the US and the target is on the west coast so there is a good deal of space between us and the connection is slow) and I am seeing the problem where the network layer is just not taking any more data so eventually something times out (if I turn off nops then scsi command timer fires and if I also increase that to 10 minutes then the EQL target will actually send me a nop and I cannot send that because the network layer just keeps returning -AGAIN). Are you still seeing that problem? Basically sendpage/sendmsg just keeps returning -EGAIN. We even get woken up by iscsi_sw_tcp_write_space, but the sk_wmem_queued and sk_sndbuf values are basically stuck and so no space ever opens up for some reason (I attached the debug patch I am using). I've used in the passed tgt with open-iscsi over an internet connection from Israel to US and it did work. Like a simple mount of ext3 and some read writes. But I've never put it into heavy load. Do you see this problem only on an heavy load or a single long dd will cause it? I tried your patch hoping it might help, but it does not help for this problem here. Maybe it is different issues. Boaz --~--~-~--~~~---~--~~ 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] libiscsi: Check for CmdSN window before sending data
On 07/23/2009 07:01 PM, Mike Christie wrote: Boaz Harrosh wrote: I think I can replicate this problem now too. It was by accident. I am using a EQL target remotely (I am in the middle of the US and the target is on the west coast so there is a good deal of space between us and the connection is slow) and I am seeing the problem where the network layer is just not taking any more data so eventually something times out (if I turn off nops then scsi command timer fires and if I also increase that to 10 minutes then the EQL target will actually send me a nop and I cannot send that because the network layer just keeps returning -AGAIN). Are you still seeing that problem? Basically sendpage/sendmsg just keeps returning -EGAIN. We even get woken up by iscsi_sw_tcp_write_space, but the sk_wmem_queued and sk_sndbuf values are basically stuck and so no space ever opens up for some reason (I attached the debug patch I am using). I've used in the passed tgt with open-iscsi over an internet connection from Israel to US and it did work. Like a simple mount of ext3 and some read writes. But I've never put it into heavy load. Do you see this problem only on an heavy load or a single long dd will cause it? Heavy load. The target has a window of 128 commands. I am setting the shost-can_queue to 1024 and the scsi_device queue_depth to 256. I then run multiple: disktest -PT -T130 -h1 -K256 -B256k -ID /dev/sdb -D 0:100 disktest -PT -T130 -h1 -K256 -B256k -ID /dev/sdb -D 0:100 disktest -PT -T130 -h1 -K256 -B256k -ID /dev/sdb -D 0:100 shost-host_busy and turn on debugging I can see the driver running 128 commands. With this the writes just die. sendpage/sendmsg just starts returning EAGAIN. I turned off nops and set the scsi cmnd timer to 1,200. And so we can go 1,200 seconds just getting -EAGAIN. The strange thing is that the network is fine on the recv side. The target is sending me a nop-in as a ping, and we are reading that in fine. Also if I just do READ tests: disktest -PT -T130 -h1 -K256 -B256k -ID /dev/sdb disktest -PT -T130 -h1 -K256 -B256k -ID /dev/sdb disktest -PT -T130 -h1 -K256 -B256k -ID /dev/sdb it works just fine. It is slow as heck. I get less than 1 MB/s throughput, but we always make forward progress. If I just set the scsi_device queue_depth to 1 and run that write workload it works just fine. What if you set scsi_device queue_depth to 126 or can_queue to 126 commandSN window left at 128 ? Boaz --~--~-~--~~~---~--~~ 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_sna_lte vs RFC1982
On 07/06/2009 02:33 PM, Hannes Reinecke wrote:
Hi Mike,
debugging my infamous iSCSI IO stall I stumbled across this:
drivers/scsi/libiscsi.c:
/* Serial Number Arithmetic, 32 bits, less than, RFC1982 */
static int iscsi_sna_lt(u32 n1, u32 n2)
{
return n1 != n2 ((n1 n2 (n2 - n1 SNA32_CHECK)) ||
(n1 n2 (n2 - n1 SNA32_CHECK)));
}
however, reading through RFC1982 it actually states:
3.2. Comparison
...
s1 is said to be less than s2 if, and only if, s1 is not equal to s2,
and
(i1 i2 and i2 - i1 2^(SERIAL_BITS - 1)) or
(i1 i2 and i1 - i2 2^(SERIAL_BITS - 1))
Do I read that correctly and shouldn't our code actually read:
return n1 != n2 ((n1 n2 (n2 - n1 SNA32_CHECK)) ||
(n1 n2 (n1 - n2 SNA32_CHECK)));
Even if the code is the same please send a patch to change it.
As is, it is totally unclear and confusing. And if you are at it
please also:
@@ -84,7 +84,7 @@ MODULE_PARM_DESC(debug_libiscsi_eh,
} while (0);
/* Serial Number Arithmetic, 32 bits, less than, RFC1982 */
-#define SNA32_CHECK 2147483648UL
+#define SNA32_CHECK 0x8000UL
static int iscsi_sna_lt(u32 n1, u32 n2)
{
---
But lets see:
Say yours is correct:
n1 - n2 0x8000
Lets apply a -(x) to both sides: (if 2 1 then -2 -1)
-(n1 - n2) -0x800
but since -0x8000 == 0x8000 on 32 bits then
n2 - n1 0x80
which is as stated above (n2 - n1 SNA32_CHECK)
?
Otherwise we'd be off by one, or am I missing something here?
Slightly confused,
Unless in 64bit machines we get funny things with u32 promoted to s64.
I'd say better change it.
Hannes
Thanks
Boaz
--~--~-~--~~~---~--~~
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: compile the latest version debian ubuntu
On 06/23/2009 11:11 AM, Stefan wrote: Am Montag 22 Juni 2009 13:51:17 schrieb Stefan: Hello all, sorry, its half solved. Its now running on ubuntu jaunty but not on debian lenny. I did what did on the ubuntu machine: aptitude install open-iscsi untar new package make user make install_user /etc/init.d/open-iscsi start iscsiadm -m session -P 3 iSCSI Transport Class version 2.0-869 This is very old what Kernel is this ? iscsiadm version 2.0-870 iscsiadm: could not read session targetname: 61 iscsiadm: could not find session info for session1 iscsiadm: Can not get list of active sessions (61) And I compile x.871 but its not shown?! iscsiadm -m discovery -t sendtargets -p 10.100.100.30 --login and nothing happens then. I have look with tcpdump port 3260 on lenny and I see that nothing is recorded. Whats wrong? try to make; make install this time. It looks like your Kernel is very old and the out-of-tree modules should be better. Can someone help? tia stefan Boaz --~--~-~--~~~---~--~~ 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: compile the latest version debian ubuntu
On 06/22/2009 10:43 AM, Stefan wrote: Am Montag 22 Juni 2009 08:59:04 schrieb Boaz Harrosh: I think for 2.6.28 Kernel the best is to run with built-in iscsi modules and only compile and install the install_user from open-iscsi. I reinstalled kernel and did the install_user install. This is working but I dont have a disk. fdisk -l dont show a disk. In /var/log/messages and dmesg I have: Loading iSCSI transport class v2.0-870. [140929.059791] iscsi: registered transport (tcp) [140929.117416] ib_iser: disagrees about version of symbol iscsi_conn_setup [140929.117422] ib_iser: Unknown symbol iscsi_conn_setup [140929.117569] ib_iser: disagrees about version of symbol iscsi_session_recovery_timedout [140929.117573] ib_iser: Unknown symbol iscsi_session_recovery_timedout [140929.118096] ib_iser: disagrees about version of symbol iscsi_conn_bind [140929.118100] ib_iser: Unknown symbol iscsi_conn_bind [140929.118370] ib_iser: disagrees about version of symbol iscsi_session_setup [140929.118373] ib_iser: Unknown symbol iscsi_session_setup [140929.119293] ib_iser: disagrees about version of symbol iscsi_conn_failure [140929.119296] ib_iser: Unknown symbol iscsi_conn_failure [140929.119429] ib_iser: disagrees about version of symbol iscsi_complete_pdu [140929.119432] ib_iser: Unknown symbol iscsi_complete_pdu [140929.119814] ib_iser: disagrees about version of symbol iscsi_register_transport [140929.119817] ib_iser: Unknown symbol iscsi_register_transport [140929.119991] ib_iser: disagrees about version of symbol __iscsi_get_task [140929.119994] ib_iser: Unknown symbol __iscsi_get_task [140929.120350] ib_iser: disagrees about version of symbol iscsi_set_param [140929.120355] ib_iser: Unknown symbol iscsi_set_param [140929.121178] ib_iser: disagrees about version of symbol iscsi_conn_get_param [140929.121184] ib_iser: Unknown symbol iscsi_conn_get_param [140929.121346] ib_iser: disagrees about version of symbol iscsi_suspend_tx [140929.121352] ib_iser: Unknown symbol iscsi_suspend_tx [140929.121673] ib_iser: disagrees about version of symbol iscsi_put_task [140929.121678] ib_iser: Unknown symbol iscsi_put_task [140929.121849] ib_iser: disagrees about version of symbol iscsi_conn_teardown [140929.121854] ib_iser: Unknown symbol iscsi_conn_teardown [140929.122173] ib_iser: disagrees about version of symbol iscsi_session_get_param [140929.122179] ib_iser: Unknown symbol iscsi_session_get_param [140929.122343] ib_iser: disagrees about version of symbol iscsi_conn_send_pdu [140929.122348] ib_iser: Unknown symbol iscsi_conn_send_pdu [140929.122711] ib_iser: disagrees about version of symbol iscsi_conn_start [140929.122717] ib_iser: Unknown symbol iscsi_conn_start [140929.122919] ib_iser: Unknown symbol iscsi_prep_unsolicit_data_pdu [140929.123593] ib_iser: disagrees about version of symbol iscsi_itt_to_ctask [140929.123598] ib_iser: Unknown symbol iscsi_itt_to_ctask [140929.124075] ib_iser: disagrees about version of symbol iscsi_host_alloc [140929.124079] ib_iser: Unknown symbol iscsi_host_alloc [140929.124768] ib_iser: disagrees about version of symbol iscsi_session_teardown [140929.124772] ib_iser: Unknown symbol iscsi_session_teardown [140929.124934] ib_iser: disagrees about version of symbol iscsi_unregister_transport [140929.124938] ib_iser: Unknown symbol iscsi_unregister_transport [140929.125146] ib_iser: disagrees about version of symbol iscsi_conn_stop [140929.125150] ib_iser: Unknown symbol iscsi_conn_stop [140929.414315] scsi9 : iSCSI Initiator over TCP/IP [140929.421590] scsi10 : iSCSI Initiator over TCP/IP [140929.428797] scsi11 : iSCSI Initiator over TCP/IP First it seems that your Kernel did not come with the iSER module. The best is to just disable it in the /etc/init.d/open-iscsi script. find the line that does: modprobe -q ib_iser and comment it out. You don't need it hmm what next? How Can I get the scsi disk? But this is harmless please do again: []$ iscsiadm -m session -P 3 like before, what is the output?? tia stefan Boaz --~--~-~--~~~---~--~~ 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
Re: compile the latest version debian ubuntu
On 06/22/2009 12:57 PM, Stefan wrote: Am Montag 22 Juni 2009 11:31:28 schrieb Boaz Harrosh: Could you redo the discovery again, with a --login. some thing like: []$ iscsiadm -m discovery -t sendtargets -p 10.100.100.30 --login send the output of that and also the iscsiadm -m session -P 3 after that. iscsiadm -m session -P 3 iSCSI Transport Class version 2.0-870 version 2.0-871 Target: iqn.fromlenny.com.openfiler:tsn.7480be2c6f3f Current Portal: 10.100.100.30:3260,1 Persistent Portal: 10.100.100.30:3260,1 ** Interface: ** Iface Name: default Iface Transport: tcp Iface Initiatorname: iqn.2005-03.org.open-iscsi:49408c98fb0 Iface IPaddress: 10.100.100.10 Iface HWaddress: empty Iface Netdev: empty SID: 1 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE Negotiated iSCSI params: HeaderDigest: None DataDigest: None MaxRecvDataSegmentLength: 262144 MaxXmitDataSegmentLength: 131072 FirstBurstLength: 262144 MaxBurstLength: 262144 ImmediateData: No InitialR2T: Yes MaxOutstandingR2T: 1 Attached SCSI devices: Host Number: 8 State: running Target: iqn.2006-01.com.openfiler:tsn.e1ed9b1eb42c Current Portal: 10.100.100.30:3260,1 Persistent Portal: 10.100.100.30:3260,1 ** Interface: ** Iface Name: default Iface Transport: tcp Iface Initiatorname: iqn.2005-03.org.open-iscsi:49408c98fb0 Iface IPaddress: 10.100.100.10 Iface HWaddress: empty Iface Netdev: empty SID: 2 iSCSI Connection State: LOGGED
Re: iSCSI initiator implementation question
On 06/18/2009 10:56 AM, Joachim Worringen wrote: Greetings, I tried to use Open-iSCSI with a non-tcp socket type and failed (timeout after connection has been established). Looking at the source, the reason is obvious: for sending data (iscsi_send()), the function pointers from sock-sk are used via the kernel socket API. This works well with non-tcp sockets. Howver, for reading data (see callback handler iscsi_tcp_data_ready()), tcp_read_sock() is used instead of the related kernel socket API call. Sounds good. Could you test out your solution and send a patch? If it tests out, I don't see why not. 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. thanks, Joachim Boaz --~--~-~--~~~---~--~~ 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: [pnfs] build open-iscsi error
On 06/12/2009 06:49 PM, sun_peix...@emc.com wrote: I have installed the latest linux.2.6.30-pnfs on my client. All modules and headers have been installed. When I was build the open-iscsi, I got the following error. My linux-pnfs source and open-iscsi source are all located under /usr/src directory. Before install 2.6.30-pnfs, my client was running RedHat Linux2.6.18. I am using gcc4.1.1 Thanks for help Peixing make[1]: Leaving directory `/usr/src/open-iscsi-2.0-870.3/usr' make -C kernel make[1]: Entering directory `/usr/src/open-iscsi-2.0-870.3/kernel' make[1]: *** No rule to make target `linux_2_6_30', needed by `kernel_check'. Stop. make[1]: Leaving directory `/usr/src/open-iscsi-2.0-870.3/kernel' make: *** [all] Error 2 From 2.6.28 open-iscsi kernel modules should not be built out-of-tree. You should only run with the iscsi modules built with your Kernel. Just go to scsi-lowlevel-drivers in your xconfig or menuconfig and enable the iscsi driver. For the user-mode iscsi utilities you do: [open-iscsi]$ make user and as su [open-iscsi]$ make install_user Cheers Boaz --~--~-~--~~~---~--~~ 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 06/11/2009 08:41 PM, Mike Christie wrote: Hey, 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 Boaz --~--~-~--~~~---~--~~ 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 06/14/2009 12:52 PM, Bart Van Assche wrote: 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. From my experience this makes users loos on the Kernel guys. Kernel guys are busy, and mind their own business, but if a question comes up, which they know the answer they would occasionally participate. Splitting will loos that. I think iscsi mailing-list is not that big and still easy to monitor. Just set your mailer to view by thread, and it's easy to jump over threads that are not interesting. My $0.017 Boaz --~--~-~--~~~---~--~~ 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: corruption in session list
On 04/28/2009 09:28 AM, Erez Zilber wrote: On Mon, Apr 27, 2009 at 6:56 PM, Mike Christie micha...@cs.wisc.edu wrote: Erez Zilber wrote: From time to time, I see errors like the following when I run 'iscsiadm -m session': tcp: [2] []:-1,1 ��A�¹V��� Is it a known bug? I don't know how to reproduce it. It just happens. I have not seen it. Have you seen it in multiple versions of open-iscsi? I'm 2 or 3 commits away from the HEAD. I haven't seen that with other versions. Do you actually have a session with sid 2 running or is it all garbage? Will check that when it happens again. Erez Make sure you do a make clean. I had a good couple of hours with such fun ;-) Boaz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
gcc warning at iscsi_add_session
drivers/scsi/scsi_transport_iscsi.c: In function 'iscsi_add_session': drivers/scsi/scsi_transport_iscsi.c:678: warning: 'err' may be used uninitialized in this function Hi mike, what ever happened to the fix of above warning? I'm sure I saw a fix in the mailing list but it never made it into mainline (2.6.30-rc3) Has it been dropped? Thanks Boaz --~--~-~--~~~---~--~~ 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: iscsiadm: InitiatorName is required on the first Login PDU
On 04/06/2009 06:18 PM, Mike Christie wrote: Boaz Harrosh wrote: then I do the above iscsiadm command above and I don't see even a single print in /var/log/messages. I do see the usual: Apr 5 20:25:47 testlin2 kernel: Loading iSCSI transport class v2.0-870. Apr 5 20:25:47 testlin2 kernel: iscsi: registered transport (tcp) What KERN_* level is it printing? One small request for me when I do It is using KERN_INFO. I noticed sometimes in rc kernels my printks do not go to /var/log/messsages, but if you do dmesg they are in there. right, I had that too. I think it is something to do with Fedora log filters. But KERN_INFO is fine, it's the best you can do. echo 1/0 */debug_*iscsi* please printk an Turning debug on/off so we can see that it works in /var/log/messages. Will do in next feature window. I tried to do that it will be hard, perhaps you should leave it as is. We can leave with it. This is because currently we are using module_param_named which registers a generic int handler for the passed int pointer. Doing the print means registering a function, which will make the code bigger. There are tricks we can do to cause printout like some query that will cause printouts for testing. Again sorry for the original noise. Every thing is now fine Thanks Boaz --~--~-~--~~~---~--~~ 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: iscsiadm: InitiatorName is required on the first Login PDU
On 04/02/2009 07:29 PM, Boaz Harrosh wrote:
Sorry, it's gating late here, I'll only get to it first thing Sunday.
Have a good weekend
Boaz
I'm back
[]$ ll /sbin/iscsi*
-rwxr-xr-x 1 root root 19836 Apr 5 11:18 /sbin/iscsi-iname
-rwxr-xr-x 1 root root 5309 Apr 5 11:18 /sbin/iscsi_discovery
-rwxr-xr-x 1 root root 723987 Apr 5 11:18 /sbin/iscsiadm
-rwxr-xr-x 1 root root 731275 Apr 5 11:18 /sbin/iscsid
-rwxr-xr-x 1 root root 792424 Oct 5 2007 /sbin/iscsistart
[]$ find ${PATH//:/ } -name iscsiadm
/sbin/iscsiadm
[]$ find ${PATH//:/ } -name iscsid
/sbin/iscsid
[]$ iscsid -d 8 -f
[1] 1119
iscsid: sysfs_init: sysfs_path='/sys'
iscsid: sysfs_attr_get_value: open '/module/scsi_transport_iscsi'/'version'
iscsid: sysfs_attr_get_value: new uncached attribute
'/sys/module/scsi_transport_iscsi/version'
iscsid: sysfs_attr_get_value: add to cache
'/sys/module/scsi_transport_iscsi/version'
iscsid: sysfs_attr_get_value: cache '/sys/module/scsi_transport_iscsi/version'
with attribute value '2.0-870'
iscsid: transport class version 2.0-870. iscsid version 2.0-871
iscsid: in ctldev_open
iscsid: created NETLINK_ISCSI socket...
iscsid: InitiatorName==iqn.2006-10.com.bhalevy:um.initiator
iscsid: InitiatorAlias==um.bhalevy.com
iscsid: InitiatorName=iqn.2006-10.com.bhalevy:um.initiator
iscsid: InitiatorAlias=um.bhalevy.com
iscsid: in ctldev_close
iscsid: Max file limits 1024 1024
iscsid: reaped pid 1120, reap_count now 0
I run iscsiadm on same consul so you can see prints from both
iscsiadm iscsid.
[]$ iscsiadm -d 9 -m discovery -t sendtargets -p 192.168.0.241:3260 --login
iscsiadm: ip 192.168.0.241, port 3260, tgpt -1
iscsiadm: Max file limits 1024 1024
iscsid: poll result 1
iscsid: mgmt_ipc_write_rsp: rsp to fd 5
iscsiadm: updating defaults from '/etc/iscsi/iscsid.conf'
iscsiadm: updated 'discovery.sendtargets.iscsi.MaxRecvDataSegmentLength',
'32768' = '32768'
iscsiadm: updated 'node.startup', 'manual' = 'manual'
iscsiadm: updated 'node.session.timeo.replacement_timeout', '120' = '120'
iscsiadm: updated 'node.conn[0].timeo.login_timeout', '30' = '15'
iscsiadm: updated 'node.conn[0].timeo.logout_timeout', '15' = '15'
iscsiadm: updated 'node.conn[0].timeo.noop_out_interval', '5' = '5'
iscsiadm: updated 'node.conn[0].timeo.noop_out_timeout', '5' = '5'
iscsiadm: updated 'node.session.err_timeo.abort_timeout', '15' = '15'
iscsiadm: updated 'node.session.err_timeo.lu_reset_timeout', '30' = '20'
iscsiadm: updated 'node.session.initial_login_retry_max', '4' = '8'
iscsiadm: updated 'node.session.cmds_max', '128' = '128'
iscsiadm: updated 'node.session.queue_depth', '32' = '32'
iscsiadm: updated 'node.session.iscsi.InitialR2T', 'No' = 'No'
iscsiadm: updated 'node.session.iscsi.ImmediateData', 'Yes' = 'Yes'
iscsiadm: updated 'node.session.iscsi.FirstBurstLength', '262144' = '262144'
iscsiadm: updated 'node.session.iscsi.MaxBurstLength', '16776192' = '16776192'
iscsiadm: updated 'node.conn[0].iscsi.MaxRecvDataSegmentLength', '262144' =
'131072'
iscsiadm: updated 'node.session.iscsi.FastAbort', 'Yes' = 'Yes'
iscsiadm: starting sendtargets discovery, address 192.168.0.241:3260,
iscsid: poll result 1
iscsid: mgmt_ipc_write_rsp: rsp to fd 5
iscsid: poll result 1
iscsid: mgmt_ipc_write_rsp: rsp to fd 5
iscsiadm: sendtargets discovery to 192.168.0.241:3260 using isid 0x00023d00
iscsiadm: discovery timeouts: login 15, reopen_cnt 5, auth 45.
iscsiadm: connecting to 192.168.0.241:3260
iscsiadm: connected local port 55107 to 192.168.0.241:3260
iscsiadm: connected to discovery address 192.168.0.241
iscsiadm: discovery session to 192.168.0.241:3260 starting iSCSI login on fd 3
iscsiadm: InitiatorName is required on the first Login PDU
iscsiadm: login failed, couldn't make a login PDU
iscsiadm: discovery login to 192.168.0.241 failed, giving up
iscsiadm: disconnecting conn 0x639040, fd 3
Same stuff. I'll try to inspect the code and put some prints to understand where
it fails. I'll start with the hunk you sent
Boaz
--~--~-~--~~~---~--~~
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: iscsiadm: InitiatorName is required on the first Login PDU
On 04/02/2009 06:39 PM, Mike Christie wrote: So I try again: [] git checkout master [] make user [r...@testlin2] make install_user then I do: [r...@testlin2]$ service open-iscsi start Starting iSCSI initiator service: [ OK ] Setting up iSCSI targets: iscsiadm: No records found! [ OK ] [r...@testlin2]$ iscsiadm -m discovery -t sendtargets -p 192.168.0.142:3260 --login iscsiadm: InitiatorName is required on the first Login PDU iscsiadm: login failed, couldn't make a login PDU iscsiadm: discovery login to 192.168.0.241 failed, giving up [r...@testlin2]$ ps ax |grep iscsi 32268 ?S 0:00 [iscsi_eh] 32284 ?Ss 0:00 iscsid 32285 ?SLs 0:00 iscsid 32313 pts/0S+ 0:00 grep iscsi If I checkout 01123e0 Update Changelog for new release which is 2.0-870 tag and do exactly like above it works, do you want that I try a bisection? Not yet. Just do iscsiadm -m discovery -t sendtargets -p 192.168.0.142:3260 --login -d 8 and send the debug output. Hey hi that was fast here: iscsiadm: Max file limits 1024 1024 iscsiadm: updating defaults from '/etc/iscsi/iscsid.conf' iscsiadm: updated 'discovery.sendtargets.iscsi.MaxRecvDataSegmentLength', '32768' = '32768' iscsiadm: updated 'node.startup', 'manual' = 'manual' iscsiadm: updated 'node.session.timeo.replacement_timeout', '120' = '120' iscsiadm: updated 'node.conn[0].timeo.login_timeout', '30' = '15' iscsiadm: updated 'node.conn[0].timeo.logout_timeout', '15' = '15' iscsiadm: updated 'node.conn[0].timeo.noop_out_interval', '5' = '5' iscsiadm: updated 'node.conn[0].timeo.noop_out_timeout', '5' = '5' iscsiadm: updated 'node.session.err_timeo.abort_timeout', '15' = '15' iscsiadm: updated 'node.session.err_timeo.lu_reset_timeout', '30' = '20' iscsiadm: updated 'node.session.initial_login_retry_max', '4' = '8' iscsiadm: updated 'node.session.cmds_max', '128' = '128' iscsiadm: updated 'node.session.queue_depth', '32' = '32' iscsiadm: updated 'node.session.iscsi.InitialR2T', 'No' = 'No' iscsiadm: updated 'node.session.iscsi.ImmediateData', 'Yes' = 'Yes' iscsiadm: updated 'node.session.iscsi.FirstBurstLength', '262144' = '262144' iscsiadm: updated 'node.session.iscsi.MaxBurstLength', '16776192' = '16776192' iscsiadm: updated 'node.conn[0].iscsi.MaxRecvDataSegmentLength', '262144' = '131072' iscsiadm: updated 'node.session.iscsi.FastAbort', 'Yes' = 'Yes' iscsiadm: starting sendtargets discovery, address 192.168.0.241:3260, iscsiadm: sendtargets discovery to 192.168.0.241:3260 using isid 0x00023d00 iscsiadm: discovery timeouts: login 15, reopen_cnt 5, auth 45. iscsiadm: connecting to 192.168.0.241:3260 iscsiadm: connected local port 53619 to 192.168.0.241:3260 iscsiadm: connected to discovery address 192.168.0.241 iscsiadm: discovery session to 192.168.0.241:3260 starting iSCSI login on fd 3 iscsiadm: InitiatorName is required on the first Login PDU iscsiadm: login failed, couldn't make a login PDU iscsiadm: discovery login to 192.168.0.241 failed, giving up iscsiadm: disconnecting conn 0xd65040, fd 3 Not much there either should I start from clean, naybe the old records break something. What to do to start with totally clean setup? Boaz --~--~-~--~~~---~--~~ 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: iscsiadm: InitiatorName is required on the first Login PDU
On 04/02/2009 07:14 PM, Mike Christie wrote: Boaz Harrosh wrote: could you just do iscsid -d 8 -f What gets spit out for the initiator name? Do you have different versions of iscsid and iscsiadm running? Could you run the discovery command with no debugging with the attached patch? should I start from clean, naybe the old records break something. It shoudn't we do not get to that point yet. What to do to start with totally clean setup? There is no nice uninstall. Let me try to write one up real quick. Sorry, it's gating late here, I'll only get to it first thing Sunday. Have a good weekend Boaz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
iscsiadm: InitiatorName is required on the first Login PDU
Hi Mike, list. In 2.0-870 I use to discover and login in the following command: []$ iscsiadm -m discovery -t sendtargets -p 192.168.0.142:3260 --login But if I compile master: I get: iscsiadm: InitiatorName is required on the first Login PDU iscsiadm: login failed, couldn't make a login PDU iscsiadm: discovery login to 192.168.0.142 failed, giving up I've renamed my /etc/iscsi to /etc/iscsi.old and reran make install_user, but same problem. Also same command as above without --login gives same error. I do have my /etc/iscsi/initiatorname.iscsi exactly as before. [Q] What do I need to add to configuration so I can do discovery? Sorry if this was posted before, I have not followed latest mails. Thanks in advance Boaz --~--~-~--~~~---~--~~ 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
Hi Mike, list. Mike Christie has pointed out of a serious problem for us which we need the list help of. It started with a question by Ulrich Windl of why data-digests are not supported/recommended by open-iscsi installations and distros. [iscsi data-digests is when the complete payload of an iscsi transaction initiator-target is signed by an HMAC(SHA1) both read/write] Mike Christie wrote: Ulrich Windl wrote: 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. Mike if what you said in the last paragraph is true, about FS modifying the data while the request is in-flight, then it does not explain your statement above about, things getting worse around the scatterlist changes. The way I see it there can be two fundamental problems: 1. The FS is permitted to (or sinfully) modifies pages of memory while a request to write these pages is already in-flight. fsdevel guys might want to comment on that? Mike have you observed these problems with a particular file system? I can anticipate such a problem arising in a memory-mapped IO, while a page-cache write-back is in progress. Is that so? is Linux not safe in this regard? If so how does DM MD do there raid parity calculations? do they copy the data? 2. iSCSI releases the request too soon, before the all data was actually used up by the network stack, and is allowing the FS to continue modifying these pages. This is a serious problem which means that there can be crashes and data corruption even if data-digest are not used. Actually we did move not long ago from copy of network data to been completely copy-less could that be the point in time things stopped working? 3. Plain coding bug, but I could not find any. I know in the passed that data-digests are a grate tool for finding bugs that otherwise can go undetected, it happened to me several times in the passed. All of these cases reviled a flaw in the code, do to rebasing, things changing, plain programmer bugs. Mike, I'm running here a plain iscsi initiator-target setup and the regression tests, and it runs. What setup and tests did you run to trigger these digest retries, I would like to reproduce this here, and investigate. Thanks for any help Boaz --~--~-~--~~~---~--~~ 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: Disable aggregation of requests
Erez Zilber wrote: You can select the no-op I/O elevator and you can also use direct IO like with sg_dd from the sg_utils package I'm using noop already, but that didn't help. I'll try to ask in lkml. Thanks, Erez Using the sg3-utils package sg_dd command you can issue individual scsi_command reads/writes with exactly the size you want. (Tell me if you need example script) Cheers Boaz --~--~-~--~~~---~--~~ 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: Disable aggregation of requests
Or Gerlitz wrote: Boaz Harrosh wrote: You can select the no-op I/O elevator and you can also use direct IO like with sg_dd from the sg_utils package Does anyone know why noop is not the default I/O scheduler? It is a very bad idea in case of using a filesystem which is usually the point. Or. --~--~-~--~~~---~--~~ 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] open-iscsi: kernel/Makefile: Better Makefile output when compiling with new Kernels
Mike Christie wrote: Boaz Harrosh wrote: In case we are compiling against a newer kernel then what the out-of-tree is expecting, Output to the user that use of in-tree modules are recommended. This will still fail the compilation. because we don't want to compile in that case. But the user can see that this is an acceptable situation and he can proceed. [Mike we could: return with @exit 0 and let the Makefile attempt a compilation, but I think it is better this way?] Signed-off-by: Boaz Harrosh bharr...@panasas.com --- kernel/Makefile |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/kernel/Makefile b/kernel/Makefile index b29cfed..9bfd5db 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -101,6 +101,11 @@ linux_2_6_28: $(unpatch_code) linux_2_6_29: $(unpatch_code) +linux_2_6_%: $(unpatch_code) +@echo Compiling against: $@ +@echo With new Kernels, use iscsi modules that came with the Kernel +@exit 1 + This actually catches distro kernels. Yes it does, Drop it for now, I'll look into it. Boaz --~--~-~--~~~---~--~~ 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: Need help in compiling open-iscsi-2.0-870.2 for kernel 2.6.28
Mike Christie wrote: Jeronimo de A. Barros wrote: Hello, Any help or hint to compile open-iscsi-2.0-870.2 for kernel 2.6.28 ? I'm trying on a Bluewhite64 12.2 running kernel 2.6.28.2: r...@test:/usr/local/src/open-iscsi-2.0-870.2# uname -a Linux test 2.6.28.2 #1 SMP Sun Feb 1 09:32:16 BRST 2009 x86_64 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux r...@test:/usr/local/src/open-iscsi-2.0-870.2# gcc -v Reading specs from /usr/lib/gcc/x86_64-pc-linux/4.2.4/specs Target: x86_64-pc-linux Configured with: ../gcc-4.2.4/configure --prefix=/usr --enable-shared --enable-languages=ada,c,c++,fortran,java,objc --disable-multilib --enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --build=x86_64-pc-linux --target=x86_64-pc-linux --host=x86_64-pc-linux Thread model: posix gcc version 4.2.4 I have inserted the line linux_2_6_28: $(unpatch_code) but still getting errors: Yeah, that is not going to work, because the 2.6.28 kernel changed some kernel APIs. The kernel modules need to be updated for the new APIs. I have done this to the code in git: git clone git://git.kernel.org/pub/scm/linux/kernel/git/mnc/open-iscsi.git I am preparing to do a new release when I finish up integrating some patches from Fedora, converting code to use strlcat and strlcpy, and fix some bugs in the iface printing code. I was planning on having this done by 2.6.29 (so the new release will have 2.6.28 and .29 support). I know this does not help you much. But the upstream 2.6.28.2 kernel is up to date with 870.1 (.2 just has one fix that 2.6.28 does not for memory leak), so you could just use those kernel modules and then use the userspace tools from open-iscsi-2.0-870.2 and you would probably be fine. Hi mike, if we are already at the subject. Something I wanted for a while. It is expected for out-of-tree Kernel modules to constantly break at the development edge. What happens today is that I can't finish compiling and installing user-mode tools, if Kernel does not compile. I want to submit a patch that will not force Kernel module compilation by default, but only if say we do make kernel. Since for me 99% of the time I just want to update on the user-mode, and I'm using the Kernel modules that come from the Kernel I'm using. Is that OK? Boaz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[PATCH 1/2] open-iscsi: Makefile: Don't build out-of-tree Kernel modules by default
Separate out the build of kernel: and user: targets. Let all: depend on user: only, though making kernel builds optional. [Mike please revisit the @echo output if we need anything added?] Signed-off-by: Boaz Harrosh bharr...@panasas.com --- Makefile | 26 +++--- 1 files changed, 15 insertions(+), 11 deletions(-) diff --git a/Makefile b/Makefile index 9578697..a6d2b88 100644 --- a/Makefile +++ b/Makefile @@ -24,27 +24,31 @@ IFACEFILES = etc/iface.example # using '$(MAKE)' instead of just 'make' allows make to run in parallel # over multiple makefile. -all: +all: user + +user: ; $(MAKE) -C utils/fwparam_ibft $(MAKE) -C usr - $(MAKE) -C kernel $(MAKE) -C utils @echo @echo Compilation complete Output file @echo --- - @echo Built iSCSI Open Interface module: kernel/scsi_transport_iscsi.ko - @echo Built iSCSI library module: kernel/libiscsi.ko - @echo Built iSCSI over TCP library module: kernel/iscsi_tcp.ko - @echo Built iSCSI over TCP kernel module: kernel/iscsi_tcp.ko @echo Built iSCSI daemon: usr/iscsid @echo Built management application:usr/iscsiadm @echo - @echo Read README file for detailed information. + @echo Use iSCSI modules from Distro kernel or run \make kernel\ + @echo Read README file for detailed information. -user: - $(MAKE) -C utils/fwparam_ibft - $(MAKE) -C utils - $(MAKE) -C usr +kernel: force + $(MAKE) -C kernel + @echo Kernel Compilation complete Output file + @echo --- + @echo Built iSCSI Open Interface module: kernel/scsi_transport_iscsi.ko + @echo Built iSCSI library module: kernel/libiscsi.ko + @echo Built iSCSI over TCP library module: kernel/libiscsi_tcp.ko + @echo Built iSCSI over TCP kernel module: kernel/iscsi_tcp.ko + +force: ; clean: $(MAKE) -C utils/fwparam_ibft clean -- 1.6.0.1 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[PATCH 2/2] open-iscsi: kernel/Makefile: Better Makefile output when compiling with new Kernels
In case we are compiling against a newer kernel then what the out-of-tree is expecting, Output to the user that use of in-tree modules are recommended. This will still fail the compilation. because we don't want to compile in that case. But the user can see that this is an acceptable situation and he can proceed. [Mike, we could return with @exit 0 and let the Makefile attempt a compilation, but I think it is better this way?] Signed-off-by: Boaz Harrosh bharr...@panasas.com --- kernel/Makefile |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/kernel/Makefile b/kernel/Makefile index b29cfed..9bfd5db 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -101,6 +101,11 @@ linux_2_6_28: $(unpatch_code) linux_2_6_29: $(unpatch_code) +linux_2_6_%: $(unpatch_code) + @echo Compiling against: $@ + @echo With new Kernels, use iscsi modules that came with the Kernel + @exit 1 + do_unpatch_code: echo Un-patching source code for use with linux-2.6.14 and up ... patch -R -E -p1 $(cur_patched) -- 1.6.0.1 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[PATCH 0/2] open-iscsi: Makefile enhancements
Mike Christie wrote: Boaz Harrosh wrote: Separate out the build of kernel: and user: targets. Let all: depend on user: only, though making kernel builds optional. I like what the patches are doing by warning the user and fixing up the output, but could we just switch up the default? I think kernel developers are going to like what you did (I do), but I do not think that is what users do most of the time. OK So I'm resending (As reply to this mail) all: is now dependent on both user: and kernel: [PATCH 1/2] open-iscsi: Makefile: separate out user: and kernel: make targets Same as before but all: depends on both user: and kernel: This will give better printouts in case of compiling with new kernels, do to the next patch. Mike please see in the user: @echo output if there are actually more files build that the user is interested about. Now it only has 2. [PATCH 2/2] open-iscsi: kernel/Makefile: Better Makefile output when compiling with new Kernels I like this one, you don't have to run very tight after the kernel progress. If compiling against old kernels it will just compile as before. But with new ones that don't need compat code or might not even compile the user is instructed to use the new Kernel's iscsi modules. Thanks Boaz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[PATCH 1/2] open-iscsi: Makefile: separate out user: and kernel: make targets
Separate out the build of kernel: and user: targets. [Mike please revisit the @echo output if we need anything added] Signed-off-by: Boaz Harrosh bharr...@panasas.com --- Makefile | 25 ++--- 1 files changed, 14 insertions(+), 11 deletions(-) diff --git a/Makefile b/Makefile index 9578697..c5ad89c 100644 --- a/Makefile +++ b/Makefile @@ -24,27 +24,30 @@ IFACEFILES = etc/iface.example # using '$(MAKE)' instead of just 'make' allows make to run in parallel # over multiple makefile. -all: +all: user kernel + +user: ; $(MAKE) -C utils/fwparam_ibft $(MAKE) -C usr - $(MAKE) -C kernel $(MAKE) -C utils @echo @echo Compilation complete Output file @echo --- - @echo Built iSCSI Open Interface module: kernel/scsi_transport_iscsi.ko - @echo Built iSCSI library module: kernel/libiscsi.ko - @echo Built iSCSI over TCP library module: kernel/iscsi_tcp.ko - @echo Built iSCSI over TCP kernel module: kernel/iscsi_tcp.ko @echo Built iSCSI daemon: usr/iscsid @echo Built management application:usr/iscsiadm @echo - @echo Read README file for detailed information. + @echo Read README file for detailed information. -user: - $(MAKE) -C utils/fwparam_ibft - $(MAKE) -C utils - $(MAKE) -C usr +kernel: force + $(MAKE) -C kernel + @echo Kernel Compilation complete Output file + @echo --- + @echo Built iSCSI Open Interface module: kernel/scsi_transport_iscsi.ko + @echo Built iSCSI library module: kernel/libiscsi.ko + @echo Built iSCSI over TCP library module: kernel/libiscsi_tcp.ko + @echo Built iSCSI over TCP kernel module: kernel/iscsi_tcp.ko + +force: ; clean: $(MAKE) -C utils/fwparam_ibft clean -- 1.6.0.1 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[PATCH 2/2] open-iscsi: kernel/Makefile: Better Makefile output when compiling with new Kernels
In case we are compiling against a newer kernel then what the out-of-tree is expecting, Output to the user that use of in-tree modules are recommended. This will still fail the compilation. because we don't want to compile in that case. But the user can see that this is an acceptable situation and he can proceed. [Mike we could: return with @exit 0 and let the Makefile attempt a compilation, but I think it is better this way?] Signed-off-by: Boaz Harrosh bharr...@panasas.com --- kernel/Makefile |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/kernel/Makefile b/kernel/Makefile index b29cfed..9bfd5db 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -101,6 +101,11 @@ linux_2_6_28: $(unpatch_code) linux_2_6_29: $(unpatch_code) +linux_2_6_%: $(unpatch_code) + @echo Compiling against: $@ + @echo With new Kernels, use iscsi modules that came with the Kernel + @exit 1 + do_unpatch_code: echo Un-patching source code for use with linux-2.6.14 and up ... patch -R -E -p1 $(cur_patched) -- 1.6.0.1 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[PATCH] iscsi tcp: bidi capable
From: Pete Wyckoff p...@padd.com
Mark iscsi_tcp as being capable of bidirectional transfers. The
bsg interface checks this bit before attempting any bidirectional
commands.
Signed-off-by: Pete Wyckoff p...@padd.com
Signed-off-by: Boaz Harrosh bharr...@panasas.com
---
drivers/scsi/iscsi_tcp.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index af092a8..9e2d4fb 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -806,6 +806,12 @@ static void iscsi_sw_tcp_session_destroy(struct
iscsi_cls_session *cls_session)
iscsi_host_free(shost);
}
+static int iscsi_tcp_slave_alloc(struct scsi_device *sdev)
+{
+ set_bit(QUEUE_FLAG_BIDI, sdev-request_queue-queue_flags);
+ return 0;
+}
+
static int iscsi_sw_tcp_slave_configure(struct scsi_device *sdev)
{
blk_queue_bounce_limit(sdev-request_queue, BLK_BOUNCE_ANY);
@@ -826,6 +832,7 @@ static struct scsi_host_template iscsi_sw_tcp_sht = {
.eh_device_reset_handler= iscsi_eh_device_reset,
.eh_target_reset_handler= iscsi_eh_target_reset,
.use_clustering = DISABLE_CLUSTERING,
+ .slave_alloc= iscsi_tcp_slave_alloc,
.slave_configure= iscsi_sw_tcp_slave_configure,
.proc_name = iscsi_tcp,
.this_id= -1,
--
1.6.0.1
--~--~-~--~~~---~--~~
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] iscsi tcp: bidi capable
Boaz Harrosh wrote: From: Pete Wyckoff p...@padd.com Mark iscsi_tcp as being capable of bidirectional transfers. The bsg interface checks this bit before attempting any bidirectional commands. Signed-off-by: Pete Wyckoff p...@padd.com Signed-off-by: Boaz Harrosh bharr...@panasas.com --- snip Mike hi, whatever happened with this patch? It is over scsi-misc but I think it should be good for iscsi tree. (Sorry) Since open-osd is apparently only going into next Kernel, sigh. Then this is fine for the next Kernel as well. (I was advertising BIDI kernels since 2.6.26, well I guess not from bsg+iscsi) Thanks Boaz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[PATCH] iscsi: Kconfig option for debug prints.
Remove the dark ages /* define debug_print */ in code, to use a Kconfig option. With a system like Kconfig, in code, commented out, configuration options are slavery and hard work. (version control, manual edit ... need I say more) I've used an int config bit-mask so more areas of code can be selected with one Koption, but mainly so that allmodconfig will not turn it on. bit-1 - will turn on prints for libiscsi. bit-2 - will turn on prints for libiscsi_tcp iscsi_tcp. More iscsi drivers should use more bits. Signed-off-by: Boaz Harrosh bharr...@panasas.com --- drivers/scsi/Kconfig| 15 +++ drivers/scsi/iscsi_tcp.c|7 --- drivers/scsi/iscsi_tcp.h|6 ++ drivers/scsi/libiscsi_tcp.c |7 --- include/scsi/libiscsi.h |3 +-- 5 files changed, 22 insertions(+), 16 deletions(-) diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index d25d21e..6ef42f6 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -352,6 +352,21 @@ config ISCSI_TCP http://open-iscsi.org +config ISCSI_DEBUG + int ISCSI debug prints + depends on SCSI_ISCSI_ATTRS + default 0 + help + This is a bit-mask that turns some debug printing to Kernel's + Messages file. Each bit turns on another area of the code: + 1 - Turn on prints from iscsi libraries. + 2 - Turns on prints from iscsi_tcp operations. + Note to programmers: Use more bits in this bit-mask for other iscsi + drivers. + If you found a problem with ISCSI, please turn this on to + help us debug the problem. Send the Messages file plus problem + description to open-iscsi@googlegroups.com mailing-list + source drivers/scsi/cxgb3i/Kconfig config SGIWD93_SCSI diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c index a566aa9..af092a8 100644 --- a/drivers/scsi/iscsi_tcp.c +++ b/drivers/scsi/iscsi_tcp.c @@ -48,13 +48,6 @@ MODULE_AUTHOR(Mike Christie micha...@cs.wisc.edu, Alex Aizman itn...@yahoo.com); MODULE_DESCRIPTION(iSCSI/TCP data-path); MODULE_LICENSE(GPL); -#undef DEBUG_TCP - -#ifdef DEBUG_TCP -#define debug_tcp(fmt...) printk(KERN_INFO tcp: fmt) -#else -#define debug_tcp(fmt...) -#endif static struct scsi_transport_template *iscsi_sw_tcp_scsi_transport; static struct scsi_host_template iscsi_sw_tcp_sht; diff --git a/drivers/scsi/iscsi_tcp.h b/drivers/scsi/iscsi_tcp.h index ca6b7bc..1341b02 100644 --- a/drivers/scsi/iscsi_tcp.h +++ b/drivers/scsi/iscsi_tcp.h @@ -25,6 +25,12 @@ #include scsi/libiscsi.h #include scsi/libiscsi_tcp.h +#if (CONFIG_ISCSI_DEBUG 2) +#define debug_tcp(fmt...) printk(KERN_INFO tcp: fmt) +#else +#define debug_tcp(fmt...) +#endif + struct socket; struct iscsi_tcp_conn; diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c index 12354c5..4c9f827 100644 --- a/drivers/scsi/libiscsi_tcp.c +++ b/drivers/scsi/libiscsi_tcp.c @@ -49,13 +49,6 @@ MODULE_AUTHOR(Mike Christie micha...@cs.wisc.edu, Alex Aizman itn...@yahoo.com); MODULE_DESCRIPTION(iSCSI/TCP data-path); MODULE_LICENSE(GPL); -#undef DEBUG_TCP - -#ifdef DEBUG_TCP -#define debug_tcp(fmt...) printk(KERN_INFO tcp: fmt) -#else -#define debug_tcp(fmt...) -#endif static int iscsi_tcp_hdr_recv_done(struct iscsi_tcp_conn *tcp_conn, struct iscsi_segment *segment); diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h index 7360e19..2421c2a 100644 --- a/include/scsi/libiscsi.h +++ b/include/scsi/libiscsi.h @@ -45,8 +45,7 @@ struct iscsi_session; struct iscsi_nopin; struct device; -/* #define DEBUG_SCSI */ -#ifdef DEBUG_SCSI +#if (CONFIG_ISCSI_DEBUG 1) #define debug_scsi(fmt...) printk(KERN_INFO iscsi: fmt) #else #define debug_scsi(fmt...) -- 1.6.0.1 --~--~-~--~~~---~--~~ 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] iscsi: Kconfig option for debug prints.
Boaz Harrosh wrote: Remove the dark ages /* define debug_print */ in code, to use a Kconfig option. With a system like Kconfig, in code, commented out, configuration options are slavery and hard work. (version control, manual edit ... need I say more) I've used an int config bit-mask so more areas of code can be selected with one Koption, but mainly so that allmodconfig will not turn it on. bit-1 - will turn on prints for libiscsi. bit-2 - will turn on prints for libiscsi_tcp iscsi_tcp. More iscsi drivers should use more bits. Signed-off-by: Boaz Harrosh bharr...@panasas.com --- drivers/scsi/Kconfig| 15 +++ drivers/scsi/iscsi_tcp.c|7 --- drivers/scsi/iscsi_tcp.h|6 ++ drivers/scsi/libiscsi_tcp.c |7 --- include/scsi/libiscsi.h |3 +-- 5 files changed, 22 insertions(+), 16 deletions(-) diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig Mike hi. These are over latest Linus. Sorry I mixed up the branches. If they don't apply to your tree any more, I'll rebase. I'm sending these because for too many times I submit some code with iscsi sources edits, because I forget to remove the edits for enabling prints. Please consider for inclusion. Thanks Boaz --~--~-~--~~~---~--~~ 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] iscsi: Kconfig option for debug prints.
Mike Christie wrote: Boaz Harrosh wrote: Boaz Harrosh wrote: Remove the dark ages /* define debug_print */ in code, to use a Kconfig option. With a system like Kconfig, in code, commented out, configuration options are slavery and hard work. (version control, manual edit ... need I say more) I've used an int config bit-mask so more areas of code can be selected with one Koption, but mainly so that allmodconfig will not turn it on. bit-1 - will turn on prints for libiscsi. bit-2 - will turn on prints for libiscsi_tcp iscsi_tcp. More iscsi drivers should use more bits. Signed-off-by: Boaz Harrosh bharr...@panasas.com --- drivers/scsi/Kconfig| 15 +++ drivers/scsi/iscsi_tcp.c|7 --- drivers/scsi/iscsi_tcp.h|6 ++ drivers/scsi/libiscsi_tcp.c |7 --- include/scsi/libiscsi.h |3 +-- 5 files changed, 22 insertions(+), 16 deletions(-) diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig Mike hi. These are over latest Linus. Sorry I mixed up the branches. If they don't apply to your tree any more, I'll rebase. It applies ok. I'm sending these because for too many times I submit some code with iscsi sources edits, because I forget to remove the edits for enabling prints. Please consider for inclusion. What about compile time vs load time? Olaf had the attached patch which does it at module load time. It is nicer for users, but I was just worried about maybe there being a perf change with all the new ifs? I was waiting to do some testing to see if there was and change, but did not get around to it. Is that too paranoid (probably other factors like our crappy locking will slow us down more than some ifs for printks right)? I don't think the performance matters because in his patch it is still commented out by a config SCSI_ISCSI_DEBUG set to n. So people can run as today. Though maybe make it an int option and not bool because this way allmodconfig will not turn it on. Note that all distros use allmodeconfig. And if it is already an int it can be a bit-mask which is the default for a single iscsi module-param which also acts as a bit-mask for all iscsi drivers. Each driver has a bit. Sure a module-param could be nice, but if we decide on the final API we can do a config only now, and add run-time later. [And for me personally a config option is just good enough. Though I admit that for a sysadmin run-time can be very nice] But please let's do something. Current situation just keeps biting me on the a.. At just the times when I don't pay attention. Tell me what you decide and I'll freshen up which ever patch you want. (Olaf patch has problems, mainly with code placements and that we added libiscsi_tcp.c, and my above proposition) Thanks Mike Boaz --~--~-~--~~~---~--~~ 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] iscsi: Kconfig option for debug prints.
Randy Dunlap wrote: Boaz Harrosh wrote: Remove the dark ages /* define debug_print */ in code, to use a Kconfig option. With a system like Kconfig, in code, commented out, configuration options are slavery and hard work. (version control, manual edit ... need I say more) I've used an int config bit-mask so more areas of code can be selected with one Koption, but mainly so that allmodconfig will not turn it on. bit-1 - will turn on prints for libiscsi. bit-2 - will turn on prints for libiscsi_tcp iscsi_tcp. More iscsi drivers should use more bits. Signed-off-by: Boaz Harrosh bharr...@panasas.com --- drivers/scsi/Kconfig| 15 +++ drivers/scsi/iscsi_tcp.c|7 --- drivers/scsi/iscsi_tcp.h|6 ++ drivers/scsi/libiscsi_tcp.c |7 --- include/scsi/libiscsi.h |3 +-- 5 files changed, 22 insertions(+), 16 deletions(-) diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index d25d21e..6ef42f6 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -352,6 +352,21 @@ config ISCSI_TCP http://open-iscsi.org +config ISCSI_DEBUG +int ISCSI debug prints +depends on SCSI_ISCSI_ATTRS +default 0 +help + This is a bit-mask that turns some debug printing to Kernel's + Messages file. Each bit turns on another area of the code: + 1 - Turn on prints from iscsi libraries. + 2 - Turns on prints from iscsi_tcp operations. Is this bit 1, bit 2, or value 1, value 2? Not clear to me. If it's bit numbers, what about bit 0? Yes you are right! Not clear at all I will fix it snip Boaz --~--~-~--~~~---~--~~ 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 untested] iscsi_tcp: Neat picking on code to make it more clear
Mike Christie wrote:
Boaz Harrosh wrote:
A buffer following an header, in case of a linear allocation
can be get at by simply doing header_pointer + 1;
I got this part, and it looks nicer.
In any way below code loads a local pointer which is never used.
I did not get this part. Do you mean task-hdr is never used?
Sorry, I meant tcp_task is never used. See below:
Also are
you saying tcp_task + 1 and task-dd_data + sizeof(*tcp_task) give
different values?
The current code is fine. Just that I stumbled on it to understand
what's going on.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/iscsi_tcp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 8685a33..4cfc85a 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -462,7 +462,7 @@ static int iscsi_sw_tcp_pdu_alloc(struct iscsi_task
*task, uint8_t opcode)
{
struct iscsi_tcp_task *tcp_task = task-dd_data;
-task-hdr = task-dd_data + sizeof(*tcp_task);
The sizeof(*tcp_task) does not actually use the value of tcp_task and it is
not used elsewhere.
+task-hdr = tcp_task + 1;
task-hdr_max = sizeof(struct iscsi_sw_tcp_hdrbuf) - ISCSI_DIGEST_SIZE;
return 0;
}
Boaz
--~--~-~--~~~---~--~~
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 untested] iscsi_tcp: Neat picking on code to make it more clear
A buffer following an header, in case of a linear allocation
can be get at by simply doing header_pointer + 1;
In any way below code loads a local pointer which is never used.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/iscsi_tcp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 8685a33..4cfc85a 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -462,7 +462,7 @@ static int iscsi_sw_tcp_pdu_alloc(struct iscsi_task *task,
uint8_t opcode)
{
struct iscsi_tcp_task *tcp_task = task-dd_data;
- task-hdr = task-dd_data + sizeof(*tcp_task);
+ task-hdr = tcp_task + 1;
task-hdr_max = sizeof(struct iscsi_sw_tcp_hdrbuf) - ISCSI_DIGEST_SIZE;
return 0;
}
--
1.6.0.1
--~--~-~--~~~---~--~~
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: [PATCH 2/2 2.6.29] cxgb3i - accelerating open-iscsi initiator
Mike Christie wrote:
Boaz Harrosh wrote:
+ if (!ddp) {
+ ddp_log_warn(%s unable to alloc ddp 0x%d, ddp disabled.\n,
+tdev-name, ppmax);
+ return 0;
+ }
+ ddp-gl_map = (struct cxgb3i_gather_list **)(ddp + 1);
+ ddp-gl_skb = (struct sk_buff **)(((char *)ddp-gl_map) +
+ ppmax *
+ sizeof(struct cxgb3i_gather_list *));
+ spin_lock_init(ddp-map_lock);
+
+ ddp-tdev = tdev;
+ ddp-pdev = uinfo.pdev;
+ ddp-max_txsz = min_t(unsigned int, uinfo.max_txsz, ULP2_MAX_PKT_SIZE);
+ ddp-max_rxsz = min_t(unsigned int, uinfo.max_rxsz, ULP2_MAX_PKT_SIZE);
Please note that from what I understand, only the out-going headers can be
big, like iscsi_cmd header. But the in-coming headers are always
size_of(struct iscsi_hdr).
So there is no symmetry here. Actually only iscsi_cmd can get big, the other
out-going
data packets are with small headers, but I guess that is an open-iscsi
limitation.
Mike correct me if I'm wrong?
Yeah, correct. Other iscsi pdus like tmfs and scsi data out could have
ahs but we do not support it. You did the code, so I assumed you only
did what you needed and could test.
On the recv side, I thought scsi cmd response or scsi data-in could have
ahses, but libiscsi_tcp/libiscsi just reads as much as it can in and
does not process it (actually it only reads in as much buffer space as
it has then fails if we overflow). I believe Olaf did this code to be
complete as he could with the existing code for the future, and to make
sure his abstraction would work for ahs if we needed it.
Yes you are right. I guess none of the targets send AHSs since otherwise
our initiator would fail on that particular packet.
It's time for me to go and look at why would a target send one.
It might be better to make a small enhancement and jump over
iscsi_hdr-hlength just throwing the data away, as a matter of error handling.
Better then failing the command completely.
That is if the AHS is just optional information.
I'll look into it.
Thanks
Boaz
--~--~-~--~~~---~--~~
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: object (osd) based iscsi
ashish wrote: Hello All, I am trying to install osd based iscsi using ibm osd simulator as target, and ibm osd initiator. and I am having problem with the initiator installation. This initiator requires patched linux- iscsi-4.0.2, I was able to successfully install linux-iscsi-4.0.2, but it is failing to connect to the osd target. So I just wanted to check whether open-iscsi supports osd command set, or can we make it work with osd command set by applying some patches. Thanks in advance. Ashish Hi I'm also adding open-osd developer mailing list. The list of tools above is very (very) old. Since then I have been maintaining more advanced patchset for the IBM-Initiator over open-iscsi, (not the old linux-iscsi), with more recent kernels. However, I have abandoned IBM-Initiator, all together, for our own, new made, initiator which we call open-osd. Our initiator is a kernel-only initiator which act as a library for in kernel users of OSD, like the pNFS-over-objects layout driver. The initiator is able to talk to an OSD1 target and was tested against IBM-OSD-SIM mentioned above, as well as against an OSD2 target. Both targets are supported concurrently. An OSD2 target that I prefer and use is the one from OSC: http://www.osc.edu/~pw/osd/index.php Please note that you need the version from the git-tree mentioned at top of page. The tar-ball offered is old and has few problems with my Initiator. You can find my initiator code in this git tree: git://git.open-osd.org/git/osd-lib.git or browse the source on the web at: http://git.open-osd.org/gitweb.cgi?p=osd-lib.git;a=summary There is also a user-mode-only OSD2 Initiator that you can play with at the OSC link above. That project offers both a target and initiator in user-mode. Also look in: http://www.open-osd.org/ for very old documentation and links which we will update soon (I hope) If you have any farther questions/problems/thoughts please feel free to email: The open-osd developer mailing list. [EMAIL PROTECTED]. You should also be able to sign up to the list on: http://www.open-osd.org/bin/view/Main/MailingList If you are still interested in the old IBM-Initiator, that can compile and run against a recent Kernel (and open-iscsi). Please tell me, and I'll send you what I have. Last I used it it did work on top of the bidi and iscsi patches that are already been accepted in latest Kernels. Good luck Boaz --~--~-~--~~~---~--~~ 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: Long CDBs
EddyQ wrote: Does open-iscsi support long CDBs? You still need one more patch: http://www.spinics.net/lists/linux-scsi/msg26927.html Mike please push it threw your tree, James has gone mute Just out of curiosity, what are you using long CDBs for? Cheers Boaz --~--~-~--~~~---~--~~ 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 address redirect ignored
On Mon, Apr 28 2008 at 20:15 +0300, Mike Christie [EMAIL PROTECTED] wrote: ptashek wrote: I have looked around the web, but haven't found a similar issue which suggests that this may be a simple config issue, which I have just not found yet. However, if anyone has any thoughts on this, please share! You did not find anything on the web, because you are the first person to report it :) open-iscsi took linux-iscsi's discovery code and login code, but when it integrated it into open-iscsi it goofed in several places. This is one of them. What target are you using? I will try to send a patch later in the week for you to test. It looks like this patch could be the beginning of what we, pNFS people, wanted. A kernel API for discovery and login. Or have I mis-understood the problem/solution. Boaz --~--~-~--~~~---~--~~ 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 0/3 ver2] iscsi bidi varlen support
On Thu, Jan 31 2008 at 20:08 +0200, Boaz Harrosh [EMAIL PROTECTED] wrote: Cheers after 1.3 years these can go in. [PATCH 1/3] iscsi: extended cdb support The varlen support is not yet in mainline for block and scsi-ml. But the API for drivers will not change. All LLD need to do is max_command to the it's maximum and be ready for bigger commands. This is what's done here. Once these commands start coming iscsi will be ready for them. [PATCH 2/3] iscsi: bidi support - libiscsi [PATCH 3/3] iscsi: bidi support - iscsi_tcp bidirectional commands support in iscsi. iSER is not yet ready, but it will not break. There is already a mechanism in libiscsi that will return error if bidi commands are sent iSER way. Pete please send me the iSER bits so we can port them to this latest version. Mike these patches are ontop of iscs branch of the iscsi git tree, they will apply but for compilation you will need to sync with Linus mainline. The patches are for the in-tree iscsi code. I own you the compat patch for the out-off-tree code, but this I will only be Sunday. If we do it fast it might get accepted to 2.6.25 merge window Everybody is invited to a party at Shila ben-yhuda 52 Tel-Aviv 9:45 pm. Drinks and wonderful see-food on us :) Boaz - Everything the same as before. But working this time. Also Pete's comment about second patch, was correct and code is now fixed. I have got Mike's Signed-off-by, on these they were tested and approved by him. So they are for scsi-misc. But ... James? is there any chance these can go into scsi-rc-fixes for the 2.6.25 kernel? The reason they are so late was mainly because of a fallout in the merge process and a bug that was introduced because of that, but they were intended to go together with bidi into 2.6.25. Also as an important client code to the bidi-api that is introduced in 2.6.25 kernel. Thanks Boaz --~--~-~--~~~---~--~~ 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: [PATCH 0/3 ver2] iscsi bidi varlen support
On Mon, Feb 18 2008 at 19:22 +0200, James Bottomley [EMAIL PROTECTED] wrote: On Mon, 2008-02-18 at 17:08 +0200, Boaz Harrosh wrote: But ... James? is there any chance these can go into scsi-rc-fixes for the 2.6.25 kernel? The reason they are so late was mainly because of a fallout in the merge process and a bug that was introduced because of that, but they were intended to go together with bidi into 2.6.25. Also as an important client code to the bidi-api that is introduced in 2.6.25 kernel. Well, I think you know the answer to that one under Linus' rules for non merge window submission. It's not a bug fix; we haven't even put it into -mm for testing and it's a pretty invasive change. James It was extensively tested by all iscsi people. It has the Sign-off-by of the iscsi maintainer. They are not new patches. But, yes you are right. I now remember the trouble we had with Linus last time. So it's 2.6.26 then. :-( . People that need it for 2.6.25 will just get it off the git tree. Boaz --~--~-~--~~~---~--~~ 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: [PATCH 2/3] iscsi: bidi support - libiscsi
On Mon, Feb 11 2008 at 17:43 +0200, Pete Wyckoff [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote on Thu, 31 Jan 2008 22:29 +0200:
iscsi bidi support at the generic libiscsi level
- prepare the additional bidi_read rlength header.
- access the right scsi_in() and/or scsi_out() side of things.
also for resid.
- Handle BIDI underflow overflow from target
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
I see you do this a bit differently than in your previous patch set.
In particular, the residual handling in libiscsi.c. (I'm editing in
a bit more context to the patch below.)
+if (scsi_bidi_cmnd(sc)
+(rhdr-flags (ISCSI_FLAG_CMD_BIDI_UNDERFLOW |
+ISCSI_FLAG_CMD_BIDI_OVERFLOW))) {
+int res_count = be32_to_cpu(rhdr-bi_residual_count);
+
+if (res_count 0
+(rhdr-flags ISCSI_FLAG_CMD_BIDI_OVERFLOW ||
+res_count = scsi_in(sc)-length))
+scsi_in(sc)-resid = res_count;
+else
+sc-result =
+(DID_BAD_TARGET 16) | rhdr-cmd_status;
+}
+
if (rhdr-flags (ISCSI_FLAG_CMD_UNDERFLOW |
ISCSI_FLAG_CMD_OVERFLOW)) {
int res_count = be32_to_cpu(rhdr-residual_count);
if (res_count 0
(rhdr-flags ISCSI_FLAG_CMD_OVERFLOW ||
res_count = scsi_bufflen(sc)))
+/* write side for bidi or uni-io set_resid */
scsi_set_resid(sc, res_count);
else
sc-result = (DID_BAD_TARGET 16) | rhdr-cmd_status;
} else if (rhdr-flags (ISCSI_FLAG_CMD_BIDI_UNDERFLOW |
ISCSI_FLAG_CMD_BIDI_OVERFLOW))
sc-result = (DID_BAD_TARGET 16) | rhdr-cmd_status;
I haven't tested this, but, consider a bidi command that results in
an overflow on the read part, and no overflow on the write part.
E.g., the user supplied a data-in buffer that wasn't big enough to
hold the returned data from the target, but the data-out buffer was
just right.
Then this code will set scsi_in(sc)-resid properly, informing the
caller that there were extra bytes that were not transferred. But
the else clause at the bottom will also set sc-result to be bad.
I don't think we want this.
Your earlier patch got rid of the second bidi_overflow handler and
just did all the logic for both bidi and non-bidi cases in a single
if clause. Seemed better.
-- Pete
You are most probably right I will investigate what happened. It looks
like I went back to some old version right? or a merge fallout
Thanks for reviewing.
Please also test latest head-of-line code if possible + iscsi patches
+ last varlen I sent.
Is there any new patches I need for 2.6.24 or head-of-line for my
osd-dev tree?
Boaz
--~--~-~--~~~---~--~~
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 0/3] iscsi bidi varlen support
Cheers after 1.3 years these can go in. [PATCH 1/3] iscsi: extended cdb support The varlen support is not yet in mainline for block and scsi-ml. But the API for drivers will not change. All LLD need to do is max_command to the it's maximum and be ready for bigger commands. This is what's done here. Once these commands start coming iscsi will be ready for them. [PATCH 2/3] iscsi: bidi support - libiscsi [PATCH 3/3] iscsi: bidi support - iscsi_tcp bidirectional commands support in iscsi. iSER is not yet ready, but it will not break. There is already a mechanism in libiscsi that will return error if bidi commands are sent iSER way. Pete please send me the iSER bits so we can port them to this latest version. Mike these patches are ontop of iscs branch of the iscsi git tree, they will apply but for compilation you will need to sync with Linus mainline. The patches are for the in-tree iscsi code. I own you the compat patch for the out-off-tree code, but this I will only be Sunday. If we do it fast it might get accepted to 2.6.25 merge window Everybody is invited to a party at Shila ben-yhuda 52 Tel-Aviv 9:45 pm. Drinks and wonderful see-food on us :) Boaz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
