RE: [Patch v4] Multisession support plus Leading Login support (pull request)

Mike Christie wrote: Merged all the patches. They should show up in a couple minutes on the kernel.org git tree. Great, thanks! Thanks for your work on this and for putting up with the coding style junk. I hate to be the-coding-style-comment-guy. No worries, I completely understand. -- Jim

[Pull Reqest] A set of minor bug fixes and enhancements

I have a set of minor changes I've made while developing the Multisession and Leading-login support that I think may be beneficial to the open-iscsi project as well. Repo: git://repo.or.cz/open-iscsi/multisession.git Tag: submitted/minor_fixes_v1 I hope they should be self-explanatory from the

iSCSI root file system in the event of connection lost

Hi there, I've been remotely booting Fedora 14 from an iSCSI target for some time. I observed however that once the Ethernet cable is unplugged, the entire OS would go crash even if the Ethernet cable is later plugged back again. I believe Fedora 14 is using open-iscsi as the initiator. So, is

Re: [Pull Reqest] A set of minor bug fixes and enhancements

On 07/08/2011 08:42 AM, Jim Ramsay wrote: I have a set of minor changes I've made while developing the Multisession and Leading-login support that I think may be beneficial to the open-iscsi project as well. Repo: git://repo.or.cz/open-iscsi/multisession.git Tag: submitted/minor_fixes_v1

Re: [Pull Reqest] A set of minor bug fixes and enhancements

On 07/08/2011 05:47 PM, Mike Christie wrote: On 07/08/2011 08:42 AM, Jim Ramsay wrote: I have a set of minor changes I've made while developing the Multisession and Leading-login support that I think may be beneficial to the open-iscsi project as well. Repo:

Re: iSCSI root file system in the event of connection lost

On 07/08/2011 02:19 PM, Hsuanyeh wrote: Hi there, I've been remotely booting Fedora 14 from an iSCSI target for some time. I observed however that once the Ethernet cable is unplugged, the entire OS would go crash even if the Ethernet cable is later plugged back again. I believe Fedora 14

Re: Loss of data on logout

2011/7/6 Mike Christie micha...@cs.wisc.edu: On 07/06/2011 11:45 AM, Joachim wrote: Hello, I am currently trying to implement an iscsi target driver for a remote storage space with tgt. At first, the driver was slow (quite normal), but worked quite well, with a testing script i wrote.

RE: unable to login to targets with be2iscsi

Seth, The CQ Error 13 is done mostly when a Fin is received. If the same problem can be repro'd on iet , can you pl capture the wireshark trace on the target. That would be very helpful. Also, if NOP's are being sent ,then, I would assume the traffic is low and wireshark would not drop

Re-negotiate iSCSI params for iSCSI root?

Hi, Which iSCSI params from the list below (from iscsiadm -m session -P 2) can be re-negotiated / set again when the root partition is on a iSCSI disk, i.e. when the session has been established during initrd? HeaderDigest: None DataDigest: None MaxRecvDataSegmentLength: 131072

chopping of the SCSI payload into iSCSI PDUs

Hi, If I have following negotiated parameters for iscsi read command then are following explained scenarios possible (I wasn't sure about scenario-1) ? MaxBurstLength = 128K FirstBurstLength = 32K MaxRecvDataSegmentLength = 8K SCSI (read) command PDU specifies total data length = 25K Which

Re: chopping of the SCSI payload into iSCSI PDUs

On 07/07/2011 04:37 PM, SR wrote: Hi, If I have following negotiated parameters for iscsi read command then are following explained scenarios possible (I wasn't sure about scenario-1) ? MaxBurstLength = 128K FirstBurstLength = 32K For reads FirstBurstLength does not come into play. It

Re: Re-negotiate iSCSI params for iSCSI root?

On 07/08/2011 05:09 AM, Martin wrote: Hi, Which iSCSI params from the list below (from iscsiadm -m session -P 2) can be re-negotiated / set again when the root partition is on a iSCSI disk, i.e. when the session has been established during initrd? HeaderDigest: None DataDigest: None