problem with kernel 2.6.28 but not with 2.6.27
Hi folks:
We are having a problem with kernel 2.6.28 and the git repository
code (the latest semi-stable code doesn't support 2.6.28). Same
hardware, same targets, the 2.6.27 kernel can see our targets, but
2.6.28.4 can't. RHEL 5.3 on one machine Centos 5.2 on another, both
x86_64, with git code from repository (needed due to lack of 2.6.28
support in the 870.3 code from what I could see).
Here is what we see
[r...@jackrabbit open-iscsi]# uname -r
2.6.27.5
[r...@jackrabbit open-iscsi]# iscsiadm --mode discovery --type
sendtargets --portal 192.168.5.117
192.168.5.117:3260,1 iqn.2008-08.com.scalableinformatics:tiburon.dos.boot.image
192.168.5.117:3260,1
iqn.2008-08.com.scalableinformatics:tiburon.seagate.flash.cd
192.168.5.117:3260,1
iqn.2008-08.com.scalableinformatics:tiburon.suse10.3.x64.install.dvd
192.168.5.117:3260,1
iqn.2008-08.com.scalableinformatics:tiburon.ubuntu.install.cd
192.168.5.117:3260,1 iqn.2008-10.com.scalableinformatics:tiburon.iscsi.boot.disk
but 2.6.28.4 doesn't
[r...@jackrabbit open-iscsi]# uname -r
2.6.28.4
[r...@jackrabbit open-iscsi]# iscsiadm --mode discovery --type
sendtargets --portal 192.168.5.117
iscsiadm: Cannot perform discovery. Initiatorname required.
iscsiadm: Discovery process to 192.168.5.117:3260 failed to create a
discovery session.
moreover, performing an explicit restart
/etc/init.d/open-iscsi restart
yields this:
[r...@jackrabbit ~]# /etc/init.d/open-iscsi restart
Stopping iSCSI initiator service: [ OK ]
Starting iSCSI initiator service: FATAL: Error inserting iscsi_tcp
(/lib/modules/2.6.28.4/kernel/drivers/scsi/iscsi_tcp.ko): Unknown
symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting ib_iser
(/lib/modules/2.6.28.4/kernel/drivers/infiniband/ulp/iser/ib_iser.ko):
Unknown symbol in module, or unknown parameter (see dmesg)
[ OK ]
Setting up iSCSI targets: Logging in to [iface: default, target:
iqn.2008-08.com.scalableinformatics:tiburon.ubuntu.install.cd, portal:
192.168.5.117,3260]
Logging in to [iface: default, target:
iqn.2008-08.com.scalableinformatics:tiburon.dos.boot.image, portal:
192.168.5.117,3260]
Logging in to [iface: default, target:
iqn.2008-08.com.scalableinformatics:tiburon.suse10.3.x64.install.dvd,
portal: 192.168.5.117,3260]
Logging in to [iface: default, target:
iqn.2008-08.com.scalableinformatics:tiburon.seagate.flash.cd, portal:
192.168.5.117,3260]
Logging in to [iface: default, target:
iqn.2008-10.com.scalableinformatics:tiburon.iscsi.boot.disk, portal:
192.168.5.117,3260]
iscsiadm: Could not login to [iface: default, target:
iqn.2008-08.com.scalableinformatics:tiburon.ubuntu.install.cd, portal:
192.168.5.117,3260]:
iscsiadm: initiator reported error (13 - daemon access denied)
iscsiadm: Could not login to [iface: default, target:
iqn.2008-08.com.scalableinformatics:tiburon.dos.boot.image, portal:
192.168.5.117,3260]:
iscsiadm: initiator reported error (13 - daemon access denied)
iscsiadm: Could not login to [iface: default, target:
iqn.2008-08.com.scalableinformatics:tiburon.suse10.3.x64.install.dvd,
portal: 192.168.5.117,3260]:
iscsiadm: initiator reported error (13 - daemon access denied)
iscsiadm: Could not login to [iface: default, target:
iqn.2008-08.com.scalableinformatics:tiburon.seagate.flash.cd, portal:
192.168.5.117,3260]:
iscsiadm: initiator reported error (13 - daemon access denied)
iscsiadm: Could not login to [iface: default, target:
iqn.2008-10.com.scalableinformatics:tiburon.iscsi.boot.disk, portal:
192.168.5.117,3260]:
iscsiadm: initiator reported error (13 - daemon access denied)
iscsiadm: Could not log into all portals. Err 13.
In the logs, I found this:
Mar 11 01:29:25 jackrabbit iscsid: peeruser_unix: unknown local user with uid 0
I traced this with some googling to the usr/mgmt_ipc.c code. The
specific code which is tossing this error is
pass = getpwuid(peercred.uid);
if (pass == NULL) {
log_error("peeruser_unix: unknown local user with uid %d",
(int) peercred.uid);
return 0;
}
Basically the code is dying on the return from the getpwuid call.
Somehow pass is set to null for peercred.uid == 0. Strange.
As a sanity check, I compiled and built this:
#include
#include
#include
main() {
struct passwd *p;
uid_t uid=0;
if ((p = getpwuid(uid)) == NULL)
perror("getpwuid() error");
else {
printf("getpwuid() returned the following info for uid %d:\n",
(int) uid);
printf(" pw_name : %s\n", p->pw_name);
printf(" pw_uid : %d\n", (int) p->pw_uid);
printf(" pw_gid : %d\n", (int) p->pw_gid);
printf(" pw_dir : %s\n", p->pw_dir);
printf(" pw_shell : %s\n", p->pw_shell);
}
}
compiling and running the code ...
[r...@jackrabbit ~]# gcc t.c -o t.x
[r...@jackrabbit ~]# ./t.x
getpwuid() returned the following info for uid 0:
pw_name : root
pw_uid
Re: How to remove all iscsi configuration.
Mike Christie wrote: > Ben Greear wrote: >> george joseph wrote: >>> Hi Ben, >>> >>> Please try the following steps. >>> >>> 1) Log out from all the connected session. >>> >>> 2) Delete the entry using iscsiadm -m discovery --portal=IP address >>> --op=delete >> Then it's safe to rm -fr the /var/lib/iscsi dir? I want to get >> rid of all of the interface config and node config as well. >> >> Something else I just hit: If I try to stop iscsi twice (without running > > For stop do you mean > > service iscsi stop > > Is this fedora? What version or what iscsi-initaitor-utils version? > >> it in between), iscsiadm hangs trying to log out the second time..probably > > It should not hang. I think it waits for a very long time :) (something > like two or four minutes). > > This should be fixed in newer versions of open-iscsi so that we fail > quickly. It is in at F10 iscsi-initiator-utils-6.2.0.871-0.0.fc10 and > F9's iscsi-initiator-utils-6.2.0.871-0.0.fc10. > >> because it can't connect to the iscsi daemons. Any clean fix for >> this, or maybe just script it to look at the process listing and >> don't call iscsiadm if no daemons are running? >> > > Yeah, that would probably be nice to have too. What was happening before > is that iscsiadm would run and if it could not contact iscsid it would > retry for X seconds. Since iscsiadm needed iscsid for the command, we > modified iscsiadm to either start iscsid or have it fail quickly (assume > that you would have started iscsid so there is no need to every wait) > (the fix depends on the version of iscsi you are running). Ok. I was testing the initiator on FC8, so it could very well be fixed already in newer releases. I wasn't waiting a full 2-4 minutes, too impatient :) I can work around this in my own code easily enough until we move to newer OS releases. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Crash tgtd and tgtadm with more than 112 volumes.
On Tue, 10 Mar 2009 23:23:30 +0100 Tomasz Chmielewski wrote: > Konrad Rzeszutek schrieb: > > On Tue, Mar 10, 2009 at 02:52:41PM -0700, Ben Greear wrote: > >> I wrote a script to create lots of iscsi volumes on loop devices. > >> > >> Seems to run fine up to 111, and then tgtd crashes and tgtadm > >> gets a buffer overflow. > >> > >> The script I used to create the problem and a capture of the > >> crash is attached. > >> > >> I'm using standard RPMs on Fedora 10, kernel > >> Linux iSCSi-test 2.6.27.15-170.2.24.fc10.x86_64 #1 SMP Wed Feb 11 23:14:31 > >> EST 2009 x86_64 x86_64 x86_64 GNU/Linux > >> > >> Let me know if I can provide any additional info. > > > > You are on the wrong mailing list. This is for the Open-iSCSI _initiator_. > > The mailing > > list you want is for the Open-iSCSI _target_, which is: > > iscsitarget-de...@lists.sourceforge.net. > > The address is s...@vger.kernel.org for a year or so, the > iscsitarget-de...@lists.sourceforge.net is an old address which is not > used any more. This part is not correct. iscsitarget-de...@lists.sourceforge.net is the mailing list for iSCSI Enterprise Target project (IET), which is not tgt project. I had maintained IET but we have never used IET mailing list for tgt. FYI, our old mailing list is stgt-de...@lists.berlios.de. > CC: s...@vger.kernel.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Possible bug, not sure if it's iscsi or not.
Ben Greear wrote: > I created a volume, which showed up as /dev/disk/by-path/foo-iscsi-... > > I then did an fdisk on it, which appeared to work: > fdisk /dev/disk/by-path/ > > After that, it no longer showed up in /dev/disk/by-path/ > but it did exist as /dev/sdc and the partition at /dev/sdc1 was writable. > The iscsi code and tools have nothing to do with making the udev paths, and for partitioning a disk the iscsi code is just a passthrough mostly sending/receiving iscsi packets to accomplish the upper layers requests, so I am not going to be much help here. Maybe you will get lucky and there will be a udev hacker here. If not then the udev list might be best. My guess: Udev probably gets some event for new partition and the iscsi udev rule is not handling it correctly and killing all the links. > This was 2.6.29-rc7 (plus my hacks, but no hacks anywhere near iscsi). > > Aside from that, seems to be working marvelously, binding to local > addresses as I wish. > > Thanks, > Ben > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: How to remove all iscsi configuration.
Ben Greear wrote: > george joseph wrote: >> Hi Ben, >> >> Please try the following steps. >> >> 1) Log out from all the connected session. >> >> 2) Delete the entry using iscsiadm -m discovery --portal=IP address >> --op=delete > > Then it's safe to rm -fr the /var/lib/iscsi dir? I want to get > rid of all of the interface config and node config as well. > > Something else I just hit: If I try to stop iscsi twice (without running For stop do you mean service iscsi stop Is this fedora? What version or what iscsi-initaitor-utils version? > it in between), iscsiadm hangs trying to log out the second time..probably It should not hang. I think it waits for a very long time :) (something like two or four minutes). This should be fixed in newer versions of open-iscsi so that we fail quickly. It is in at F10 iscsi-initiator-utils-6.2.0.871-0.0.fc10 and F9's iscsi-initiator-utils-6.2.0.871-0.0.fc10. > because it can't connect to the iscsi daemons. Any clean fix for > this, or maybe just script it to look at the process listing and > don't call iscsiadm if no daemons are running? > Yeah, that would probably be nice to have too. What was happening before is that iscsiadm would run and if it could not contact iscsid it would retry for X seconds. Since iscsiadm needed iscsid for the command, we modified iscsiadm to either start iscsid or have it fail quickly (assume that you would have started iscsid so there is no need to every wait) (the fix depends on the version of iscsi you are running). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: How to remove all iscsi configuration.
Ben Greear wrote: > > Is there a clean way to remove all iSCSI configuration from > a system configured as initializers? > Not really. > I was thinking maybe: > > # On a Fedora system with the default iscsi rpms installed: > /etc/init.d/iscsi stop > rm -fr /var/lib/iscsi > This is fine. > When I start it again will it recreate directories as needed? > It will. --~--~-~--~~~---~--~~ 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: Crash tgtd and tgtadm with more than 112 volumes.
Tomasz Chmielewski wrote: >>> Let me know if I can provide any additional info. >> You are on the wrong mailing list. This is for the Open-iSCSI _initiator_. >> The mailing >> list you want is for the Open-iSCSI _target_, which is: >> iscsitarget-de...@lists.sourceforge.net. > > The address is s...@vger.kernel.org for a year or so, the > iscsitarget-de...@lists.sourceforge.net is an old address which is not > used any more. > > CC: s...@vger.kernel.org Thanks, I tried to forward it off to stgt, hopefully it will make it. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Crash tgtd and tgtadm with more than 112 volumes.
Konrad Rzeszutek schrieb: > On Tue, Mar 10, 2009 at 02:52:41PM -0700, Ben Greear wrote: >> I wrote a script to create lots of iscsi volumes on loop devices. >> >> Seems to run fine up to 111, and then tgtd crashes and tgtadm >> gets a buffer overflow. >> >> The script I used to create the problem and a capture of the >> crash is attached. >> >> I'm using standard RPMs on Fedora 10, kernel >> Linux iSCSi-test 2.6.27.15-170.2.24.fc10.x86_64 #1 SMP Wed Feb 11 23:14:31 >> EST 2009 x86_64 x86_64 x86_64 GNU/Linux >> >> Let me know if I can provide any additional info. > > You are on the wrong mailing list. This is for the Open-iSCSI _initiator_. > The mailing > list you want is for the Open-iSCSI _target_, which is: > iscsitarget-de...@lists.sourceforge.net. The address is s...@vger.kernel.org for a year or so, the iscsitarget-de...@lists.sourceforge.net is an old address which is not used any more. CC: s...@vger.kernel.org -- Tomasz Chmielewski http://wpkg.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Crash tgtd and tgtadm with more than 112 volumes.
On Tue, Mar 10, 2009 at 02:52:41PM -0700, Ben Greear wrote: > I wrote a script to create lots of iscsi volumes on loop devices. > > Seems to run fine up to 111, and then tgtd crashes and tgtadm > gets a buffer overflow. > > The script I used to create the problem and a capture of the > crash is attached. > > I'm using standard RPMs on Fedora 10, kernel > Linux iSCSi-test 2.6.27.15-170.2.24.fc10.x86_64 #1 SMP Wed Feb 11 23:14:31 > EST 2009 x86_64 x86_64 x86_64 GNU/Linux > > Let me know if I can provide any additional info. You are on the wrong mailing list. This is for the Open-iSCSI _initiator_. The mailing list you want is for the Open-iSCSI _target_, which is: iscsitarget-de...@lists.sourceforge.net. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Crash tgtd and tgtadm with more than 112 volumes.
I wrote a script to create lots of iscsi volumes on loop devices. Seems to run fine up to 111, and then tgtd crashes and tgtadm gets a buffer overflow. The script I used to create the problem and a capture of the crash is attached. I'm using standard RPMs on Fedora 10, kernel Linux iSCSi-test 2.6.27.15-170.2.24.fc10.x86_64 #1 SMP Wed Feb 11 23:14:31 EST 2009 x86_64 x86_64 x86_64 GNU/Linux Let me know if I can provide any additional info. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~--- # Found this in /var/log/messages tgtd[2665]: segfault at 90 ip 003185c0c231 sp 7fff7528fab0 error 4 in libpthread-2.9.so[3185c0+17000] # This is output from my script as it's createing things. ... Running -:tgtadm --lld iscsi --op new --mode logicalunit --tid 111 --lun 1 -b /dev/loop111:- Running -:tgtadm --lld iscsi --op bind --mode target --tid 111 -I ALL:- Running -:cp /export/iscsi/disk.100m.ext3 /export/iscsi/disk112:- Running -:losetup /dev/loop112 /export/iscsi/disk112:- Running -:tgtadm --lld iscsi --op new --mode target --tid=112 --targetname iqn.2009-02.com.lanforge:for.all.112:- Running -:tgtadm --lld iscsi --op new --mode logicalunit --tid 112 --lun 1 -b /dev/loop112:- *** buffer overflow detected ***: tgtadm terminated === Backtrace: = /lib64/libc.so.6(__fortify_fail+0x37)[0x31850ff4c7] /lib64/libc.so.6[0x31850fd370] /lib64/libc.so.6(__read_chk+0x28)[0x31850fd8a8] tgtadm[0x4010be] tgtadm[0x401f17] /lib64/libc.so.6(__libc_start_main+0xe6)[0x318501e576] tgtadm[0x400c59] === Memory map: 0040-00404000 r-xp fd:00 834180 /usr/sbin/tgtadm 00603000-00605000 rw-p 3000 fd:00 834180 /usr/sbin/tgtadm 00b05000-00b28000 rw-p 00b05000 00:00 0 [heap] 3183c0-3183c2 r-xp fd:00 3760356 /lib64/ld-2.9.so 3183e1f000-3183e2 r--p 0001f000 fd:00 3760356 /lib64/ld-2.9.so 3183e2-3183e21000 rw-p 0002 fd:00 3760356 /lib64/ld-2.9.so 318500-3185168000 r-xp fd:00 3760461 /lib64/libc-2.9.so 3185168000-3185368000 ---p 00168000 fd:00 3760461 /lib64/libc-2.9.so 3185368000-318536c000 r--p 00168000 fd:00 3760461 /lib64/libc-2.9.so 318536c000-318536d000 rw-p 0016c000 fd:00 3760461 /lib64/libc-2.9.so 318536d000-3185372000 rw-p 318536d000 00:00 0 3192a0-3192a16000 r-xp fd:00 3760493 /lib64/libgcc_s-4.3.2-20081105.so.1 3192a16000-3192c16000 ---p 00016000 fd:00 3760493 /lib64/libgcc_s-4.3.2-20081105.so.1 3192c16000-3192c17000 rw-p 00016000 fd:00 3760493 /lib64/libgcc_s-4.3.2-20081105.so.1 7f1af8b1-7f1af8b12000 rw-p 7f1af8b1 00:00 0 7f1af8b28000-7f1af8b2a000 rw-p 7f1af8b28000 00:00 0 7fff00b14000-7fff00b29000 rw-p 7ffea000 00:00 0 [stack] 7fff00bfe000-7fff00bff000 r-xp 7fff00bfe000 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Running -:tgtadm --lld iscsi --op bind --mode target --tid 112 -I ALL:- tgtadm: can't connect to the tgt daemon, Connection refused tgtadm: can't send the request to the tgt daemon, Transport endpoint is not connected Running -:cp /export/iscsi/disk.100m.ext3 /export/iscsi/disk113:- Running -:losetup /dev/loop113 /export/iscsi/disk113:- Running -:tgtadm --lld iscsi --op new --mode target --tid=113 --targetname iqn.2009-02.com.lanforge:for.all.113:- tgtadm: can't connect to the tgt daemon, Connection refused tgtadm: can't send the request to the tgt daemon, Transport endpoint is not connected Running -:tgtadm --lld iscsi --op new --mode logicalunit --tid 113 --lun 1 -b /dev/loop113:- tgtadm: can't connect to the tgt daemon, Connection refused tgtadm: can't send the request to the tgt daemon, Transport endpoint is not connected Running -:tgtadm --lld iscsi --op bind --mode target --tid 113 -I ALL:- tgtadm: can't connect to the tgt daemon, Connection refused tgtadm: can't send the request to the tgt daemon, Transport endpoint is not connected create_iscsi_targets.pl Description: Perl program
What Mistakes Men Do When They Approach Women
Dating Tips For Teens http://secret-dating.we.bs/dating-tips068.html How to Set Goals to Meet, Date, Attract, and Seduce More Women http://secret-dating.we.bs/dating-tips069.html What Mistakes Men Do When They Approach Women http://secret-dating.we.bs/dating-tips070.html --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Heidi Montag hot bikini boobs Pictures !!
Heidi Montag hot bikini boobs Pictures !! http://www.topsexymodel.info/sexy-women-picture-002.html Christina Milian gorgeous in her bikini !! http://www.topsexymodel.info/sexy-women-picture-001.html Jennifer Love Hewitt Pregnant Very Boob Model !! http://www.topsexymodel.info/Jennifer-Love-Hewitt-Pregnant.html Petra Namcova Czech Republic super sexy model and actress !! http://www.topsexymodel.info/sexy-women-picture-006.html --~--~-~--~~~---~--~~ 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: Possible bug in open-iSCSI
On Tue, Mar 10, 2009 at 12:34:55PM +0530, sushrut shirole wrote: > > Hi All, Hey Sushrut, I am also cross-posting my response to the linux-scsi mailing list in case they have insight in this problem. > I am currently guiding few students who are working on unh-iSCSI > target. Currently we are simulating some faults at a target side . > Like we are adding an error injection module to unh-iSCSI , so that > one can test how initiator behaves on particular error . > as a part of it we injects a fault in report LUN size . where we > report a wrong LUN size . ( Suppose a LUN is of size 2 gb we report it > as a 4 gb ).(Microsoft and open-iSCSI initiators we are using ).When > we try formatting this LUN on open-iSCSI initiator it formats this LUN > . In fact it doesn't give any error when we try to read or lseek 4gb > of data . But on Microsoft initiator we get an error when we try to > format this LUN . So is this a bug of open-iSCSI or this is bug of > read lseek ? The Open-iSCSI does not investigate any SCSI commands (except the AEN which gets is own special iSCSI PDU header). What you are looking at is the SCSI middle-layer, or the block-device layer, or the target not reporting an error, at being potentially faulty. What Linux kernel does when you lseek to a location past 2GB and do a read, is to transmute the request to a SCSI READ command. That SCSI READ command (you can see what the fields look like when you capture it under ethereal) specifies what sector it wants. Open-iSCSI wraps that SCSI command in its own header and puts it in a TCP packet destined to the target. The the target should then report a failure (sending a SCSI SENSE value reporting a problem). Now it might be that SCSI middle layer doesn't understand that error condition and passes it on as OK. Or it might be that the target doesn't report a failure and returns garbage/null data. What I would suggest is to do a comparison. Create a test setup where you have a real 4GB LUN, do a lseek/read above 2GB and capture all of that traffic using wireshark/ethereal. Then do the same test but with a 2GB LUN that looks like a 4GB and see what the traffic looks like. If it looks the same then somehow the target isn't reporting the right error. Which implies that when Microsoft formats the disks they verify it - by rereading the data they wrote in and failing if the doesn't match. Which might not be what mkfs.ext3 does under Linux - look in the man-page to find out. But by using lseek/read (or just do a dd with the skip argument - look in the manpage for more details) a couple of times on the same sector and you should see different data as well. If the TCP dump looks different, and the target reports a error and the Linux kernel doesn't do anything then it is time to dig through the code (scsi_error.c) to find why Linux doesn't see it as. Make sure you do use the latest kernel thought - which as of today is 2.6.29-rc7-git3. And if you do find the problem post a patch on the linux-scsi mailing list. > > -- > Thanks, Hope this lengthy explanation helps in your endeavor. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Possible bug in open-iSCSI
Hi All, I am currently guiding few students who are working on unh-iSCSI target. Currently we are simulating some faults at a target side . Like we are adding an error injection module to unh-iSCSI , so that one can test how initiator behaves on particular error . as a part of it we injects a fault in report LUN size . where we report a wrong LUN size . ( Suppose a LUN is of size 2 gb we report it as a 4 gb ).(Microsoft and open-iSCSI initiators we are using ).When we try formatting this LUN on open-iSCSI initiator it formats this LUN . In fact it doesn't give any error when we try to read or lseek 4gb of data . But on Microsoft initiator we get an error when we try to format this LUN . So is this a bug of open-iSCSI or this is bug of read lseek ? -- Thanks, Sushrut Shirole Dev Engineer. Calsoft pvt. ltd. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
