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
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 gi
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
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_
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: git://repo.or.cz/open-i
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 Fedo
2011/7/6 Mike Christie :
> 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.
>> Then, I
2011/7/6 Mike Christie :
> On 07/06/2011 04:01 PM, David Pineau wrote:
>> What seemed strange to me is that without the sync command, my driver
>> did not update many blocs/sectors on my storage, even though I did
>> properly umount and logout. To sum it up, I could not find where were
>> the lost
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 pa
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
MaxXmitDataSegment
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 scena
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 pla
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: No
13 matches
Mail list logo
