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: Long CDBs
Just trying to get my code fully tested. Eddy -Original Message- From: open-iscsi@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Boaz Harrosh Sent: Wednesday, June 04, 2008 4:15 AM To: open-iscsi@googlegroups.com; Mike Christie; EddyQ Subject: 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: umounting an iSCSI device with no connection
So I just tried issuing a logout with iscsiadm. After this I was able to umount and reboot no problem. Even though the iSCSI device can't respond does this command set something in the Kernel when it doesn't receive an ACK? -JD On Jun 2, 3:16 am, Tomasz Chmielewski [EMAIL PROTECTED] wrote: An Oneironaut schrieb: Hey all, So I'm having some problems using umount an my iSCSI device. I have my timeout period set to a really long time and the no-op timers have been switched off. If my system loses its connection to the iSCSI and I try to umount the device the command hangs. I've tried umount with the 'l' flag and the 'f' flag but neither have worked. And when I do this I am not able to kill the process even with kill -9. I've tried killing all the processes associate with the mount before umounting it. But nothing seems to work. Even when I try to reboot my system will hang requiring a hard reset. I've tried 'reboot -f' and 'reboot -n' but neither work. Has anyone run into this before or have any ideas how I can achieve either a umount or a successful reboot? Well, if you have a really long timeout and your connection is lost, umount and everything else will - not surprisingly - timeout with the period you specified. Your solutions are: - restore the connection - if possible, try to decrease the timeout just before loosing the connection - if the connection is lost already, you may also try to decrease the timeout, but I'm not sure it'll work, - don't shut your network interfaces down when rebooting or halting the system (distro-specific; for Debian, look into /etc/init.d/halt and NETDOWN / $netdown; others may use $HALTARGS variable in /etc/init.d/halt etc.). An example for setting the timeout to 120 seconds: iscsiadm -m node -T iqn.2007-05.net.my:store.backup -o update -n node.session.timeo.replacement_timeout -v 120 -- Tomasz Chmielewskihttp://wpkg.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Rejection I/O to dead device
Wanted to update on this issues again ... It just means that userspace tried to set a feature the kernel did not support. It is not serious. If there was nothing before that first line about the kernel reporting a connection error, then the target could have initiated this. Do you see anything in the target logs? What target is this again? Target is: Centos51 box also. We have noticed this to happen on this one client (centos51 also) every 2-3 days ... This client seems to do a lot of FS-related testing, not against the iscsiRoot I/O to another FS-mounted system. No messages in the target logs pertaining to this particular client and its iscsi target. Today the same symptom occurred again, I was able to scribble the messages in the console ... (now, I have a terminal server console hooked-up and I'm capturing its output in file so I will have a more complete logging info): psid 0 of 1 psid 0 of 1 oversize name in psid 0 of 1 psid 0 of 1 | | readdir corruption in 000 psid 0 of 1 readdir corruption in 000 | | iscsi: cmd 0x2a is not queued (6) end_request: I/O error dev sde; sector 50640 | | Buffer I/O error on device sde1, logical block 6323 last page write due to I/O error on sde 1 iscsi: cmd 0x2a is not queued (6) Aborting journal on device sde1 iscsi: cmd 0x2a is not queued (6) sd 6:0:0:0 rejection I/O to device being mounted (this repeats a few times) | | EXT3-fs error (device sde1): ext3_find_entry: reading directory 96001 offset 0 .. | --- I upgraded this server with a new iscsiRoot image that incorporates Mike's suggestion to increase timeout specific for iscsiRoot type connections ... would it be possible inaccessibility of root device is possibly cause by this? thanks in advance, - aspasia. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
iscsiRoot's access lost for a few seconds
Hello all, I have been wondering a given scenario, where a server boots linux over iscsiRoot; how would iscsi initiator handle, if for instance, access to the iscsiRoot device is interrupted for a second or two. A situation where this could possibly occur would be if one would add a new target in the /etc/ietd.conf in the iscsi-target host, and then do a restart, while certain hosts are booted against an iscsiRoot served by that same target. Any thoughts? Have there been any past discussions on this or any papers/techtips that may address this kind of situation? thanks in advance, - aspasia. -- A S P A S I A . . . . . . . . . . .. --~--~-~--~~~---~--~~ 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: iscsiRoot's access lost for a few seconds
a s p a s i a wrote: Hello all, I have been wondering a given scenario, where a server boots linux over iscsiRoot; how would iscsi initiator handle, if for instance, access to the iscsiRoot device is interrupted for a second or two. A situation where this could possibly occur would be if one would add a new target in the /etc/ietd.conf in the iscsi-target host, and then do a restart, while certain hosts are booted against an iscsiRoot served by that same target. This is what the replacement timeout is for. Section 8 in the README tries to describe how all those timers and scsi retries works. It is a little confusing, because some of the info on timeouts and retries is valuable for root and multipath but is only in the multipath section. Each scsi command gets 5 retries. If you were to disrupt iscsi service by pulling cables or restarting targets then if the scsi command's execution gets disrupted more than 5 times you will get a error to the FS. For each disruption you have replacement_timeout seconds to relogin to the target. If replacement_timeout expires then it does not matter how many scsi command retries you have left, the command will be failed and you will get an error to the FS. You really really want to use dm-multipath with iscsi. With dm-multipath there are lots of fun settings for if all paths should fail or look like they have failed (for example if you reboot the target or pull cables). Any thoughts? Have there been any past discussions on this or any papers/techtips that may address this kind of situation? It has been discussed a lot on the list and that is why I tried to comment on it in the README. If you could read that and give me some feedback so it is more useful for others in the future it would be helpful. --~--~-~--~~~---~--~~ 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: Rejection I/O to dead device
a s p a s i a wrote: Wanted to update on this issues again ... It just means that userspace tried to set a feature the kernel did not support. It is not serious. If there was nothing before that first line about the kernel reporting a connection error, then the target could have initiated this. Do you see anything in the target logs? What target is this again? Target is: Centos51 box also. What target is running on Centos? Is it IET or stgt or something else? Buffer I/O error on device sde1, logical block 6323 last page write due to I/O error on sde 1 iscsi: cmd 0x2a is not queued (6) Aborting journal on device sde1 iscsi: cmd 0x2a is not queued (6) This means we either got a error from the target and we tried to relogin, but we ended up killing the session because either the target told us it was going away permantly or we bugged out and could not handle the problem. What are you running on the initiator side? Is that Centos 5.1 too? Are you using the initiator that comes with it or a open-iscsi.org release? What we need is some iscsid outpout which would be a little bit before the log output you sent which would tell us why it decided to kill the session. It would be something about a bug or fatal error or could not log into target. --~--~-~--~~~---~--~~ 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: Rejection I/O to dead device
Mike Christie wrote: a s p a s i a wrote: Wanted to update on this issues again ... It just means that userspace tried to set a feature the kernel did not support. It is not serious. If there was nothing before that first line about the kernel reporting a connection error, then the target could have initiated this. Do you see anything in the target logs? What target is this again? Target is: Centos51 box also. What target is running on Centos? Is it IET or stgt or something else? Oh yeah, are you doing anything on the target? Rebooting it? Changing the config? Adding or removing targets or portals? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: umounting an iSCSI device with no connection
An Oneironaut wrote: So I just tried issuing a logout with iscsiadm. After this I was able to umount and reboot no problem. Even though the iSCSI device can't respond does this command set something in the Kernel when it doesn't receive an ACK? If the connection is not up, and you run iscsiadm ... -u, then we basically just fail all IO that comes to us and was in the process of being executed. So you will get fs and block errors and you can unmount, but any data that needed to be written is lost. Doing this is just a way to unjam the system. It is not safe. -JD On Jun 2, 3:16 am, Tomasz Chmielewski [EMAIL PROTECTED] wrote: An Oneironaut schrieb: Hey all, So I'm having some problems using umount an my iSCSI device. I have my timeout period set to a really long time and the no-op timers have been switched off. If my system loses its connection to the iSCSI and I try to umount the device the command hangs. I've tried umount with the 'l' flag and the 'f' flag but neither have worked. And when I do this I am not able to kill the process even with kill -9. I've tried killing all the processes associate with the mount before umounting it. But nothing seems to work. Even when I try to reboot my system will hang requiring a hard reset. I've tried 'reboot -f' and 'reboot -n' but neither work. Has anyone run into this before or have any ideas how I can achieve either a umount or a successful reboot? Well, if you have a really long timeout and your connection is lost, umount and everything else will - not surprisingly - timeout with the period you specified. Your solutions are: - restore the connection - if possible, try to decrease the timeout just before loosing the connection - if the connection is lost already, you may also try to decrease the timeout, but I'm not sure it'll work, - don't shut your network interfaces down when rebooting or halting the system (distro-specific; for Debian, look into /etc/init.d/halt and NETDOWN / $netdown; others may use $HALTARGS variable in /etc/init.d/halt etc.). An example for setting the timeout to 120 seconds: iscsiadm -m node -T iqn.2007-05.net.my:store.backup -o update -n node.session.timeo.replacement_timeout -v 120 -- Tomasz Chmielewskihttp://wpkg.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: iscsiRoot's access lost for a few seconds
Thanks for the response!! I will thoroughly review the readme and feedback any observations. One question - how do I check whether the config parameter change has been set correctly? Do I just look at the config file in the /etc/iscsi/nodes/ etc/default? does not seem to show in iscsiadm -m session -P 1, 2 or 3 level thanks again - I am running a script overnight to soak and see if any networking hiccups would reproduce the symptoms now that I have changed the timeout value ... - a. On 6/4/08, Mike Christie [EMAIL PROTECTED] wrote: a s p a s i a wrote: Hello all, I have been wondering a given scenario, where a server boots linux over iscsiRoot; how would iscsi initiator handle, if for instance, access to the iscsiRoot device is interrupted for a second or two. A situation where this could possibly occur would be if one would add a new target in the /etc/ietd.conf in the iscsi-target host, and then do a restart, while certain hosts are booted against an iscsiRoot served by that same target. This is what the replacement timeout is for. Section 8 in the README tries to describe how all those timers and scsi retries works. It is a little confusing, because some of the info on timeouts and retries is valuable for root and multipath but is only in the multipath section. Each scsi command gets 5 retries. If you were to disrupt iscsi service by pulling cables or restarting targets then if the scsi command's execution gets disrupted more than 5 times you will get a error to the FS. For each disruption you have replacement_timeout seconds to relogin to the target. If replacement_timeout expires then it does not matter how many scsi command retries you have left, the command will be failed and you will get an error to the FS. You really really want to use dm-multipath with iscsi. With dm-multipath there are lots of fun settings for if all paths should fail or look like they have failed (for example if you reboot the target or pull cables). Any thoughts? Have there been any past discussions on this or any papers/techtips that may address this kind of situation? It has been discussed a lot on the list and that is why I tried to comment on it in the README. If you could read that and give me some feedback so it is more useful for others in the future it would be helpful. -- A S P A S I A . . . . . . . . . . .. --~--~-~--~~~---~--~~ 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: Rejection I/O to dead device
Oh yeah, are you doing anything on the target? Rebooting it? Changing the config? Adding or removing targets or portals? in the target when the /etc/ietd.conf file is updated with a new iscsi root, a brief service iscsi-target restart occurs we're thinking of just keeping a static list and not bother it any longer - a. On 6/4/08, Mike Christie [EMAIL PROTECTED] wrote: Mike Christie wrote: a s p a s i a wrote: Wanted to update on this issues again ... It just means that userspace tried to set a feature the kernel did not support. It is not serious. If there was nothing before that first line about the kernel reporting a connection error, then the target could have initiated this. Do you see anything in the target logs? What target is this again? Target is: Centos51 box also. What target is running on Centos? Is it IET or stgt or something else? Oh yeah, are you doing anything on the target? Rebooting it? Changing the config? Adding or removing targets or portals? -- A S P A S I A . . . . . . . . . . .. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
