Eli Dorfman wrote:
>> For discovery though it seems like you can just do discovery and tell
>> iscsiadm not to overwrite the existing db (just add new ones) and that
>> would solve some of the issues with iser records getting wacked.
>>
Sorry for the late response. I was on vacation.
> How do we
> Yes, this looks okay. However, I would _really_ like to test it against
> the STP scenario.
> Hmm. I see if I can pull it in for SLES11. Care to open a bugzilla?
>
On which bugzilla do you want me to open the bug?
It will be great if you will managed to fix it.
Thanks,
Doron
--~--~-
Doron Shoham wrote:
>> If you promise to test me the script with the STP fixes I'll be willing
>> to add it. Sadly I don't have time currently to do any decent testing here,
>> but I'm always open to patches :-)
>>
>> Cheers,
>>
>> Hannes
>
> Hi Hannes,
>
> Unfortunately I don't have any setup w
> If you promise to test me the script with the STP fixes I'll be willing
> to add it. Sadly I don't have time currently to do any decent testing here,
> but I'm always open to patches :-)
>
> Cheers,
>
> Hannes
Hi Hannes,
Unfortunately I don't have any setup which I could test any script with
> For discovery though it seems like you can just do discovery and tell
> iscsiadm not to overwrite the existing db (just add new ones) and that
> would solve some of the issues with iser records getting wacked.
>
How do we tell iscsiadm not to overwrite the existing db?
Also maybe i missed someth
Hi Doron,
Doron Shoham wrote:
>> Actually this was bad. If we have to wait for the login_timeout to fire
>> then initial_login_retry_max = 4 was a nice round number and the max
>> time we had to wait was 1 minute. If I just increase it (tried 45
>> stupidly first), it increases the possible max d
Doron Shoham wrote:
>> Actually this was bad. If we have to wait for the login_timeout to fire
>> then initial_login_retry_max = 4 was a nice round number and the max
>> time we had to wait was 1 minute. If I just increase it (tried 45
>> stupidly first), it increases the possible max default wait
> Actually this was bad. If we have to wait for the login_timeout to fire
> then initial_login_retry_max = 4 was a nice round number and the max
> time we had to wait was 1 minute. If I just increase it (tried 45
> stupidly first), it increases the possible max default wait to 11
> minutes :(
>
>
Mike Christie wrote:
> Hannes Reinecke wrote:
>> On Tue, Sep 23, 2008 at 12:13:19PM -0500, Mike Christie wrote:
>>> Hannes Reinecke wrote:
Hi Doron,
Doron Shoham wrote:
> Doron Shoham wrote:
>> Hi,
>>
>> Why does the init script on suse re-discovers all iscsi targets whic
Hannes Reinecke wrote:
> On Tue, Sep 23, 2008 at 12:13:19PM -0500, Mike Christie wrote:
>> Hannes Reinecke wrote:
>>> Hi Doron,
>>> Doron Shoham wrote:
Doron Shoham wrote:
> Hi,
>
> Why does the init script on suse re-discovers all iscsi targets which
> were set
> to auto
Eli Dorfman wrote:
> On Tue, Sep 23, 2008 at 8:04 PM, Mike Christie <[EMAIL PROTECTED]> wrote:
>> Doron Shoham wrote:
>>> Hi,
>>>
>>> Why does the init script on suse re-discovers all iscsi targets which were
>>> set
>>> to automatic login?
>>> To avoid deadlocks on the root fs there is patch whi
On Tue, Sep 23, 2008 at 8:04 PM, Mike Christie <[EMAIL PROTECTED]> wrote:
>
> Doron Shoham wrote:
>> Hi,
>>
>> Why does the init script on suse re-discovers all iscsi targets which were
>> set
>> to automatic login?
>> To avoid deadlocks on the root fs there is patch which limits the number of
>
On Tue, Sep 23, 2008 at 12:13:19PM -0500, Mike Christie wrote:
> Hannes Reinecke wrote:
>> Hi Doron,
>> Doron Shoham wrote:
>>> Doron Shoham wrote:
Hi,
Why does the init script on suse re-discovers all iscsi targets which
were set
to automatic login?
To avoid deadloc
Mike Christie wrote:
> Doron Shoham wrote:
>> Hi,
>>
>> Why does the init script on suse re-discovers all iscsi targets which
>> were set
>> to automatic login?
>> To avoid deadlocks on the root fs there is patch which limits the
>> number of retries on first login.
>> When doing so, it sets bac
Hannes Reinecke wrote:
> Hi Doron,
>
> Doron Shoham wrote:
>> Doron Shoham wrote:
>>> Hi,
>>>
>>> Why does the init script on suse re-discovers all iscsi targets which
>>> were set
>>> to automatic login?
>>> To avoid deadlocks on the root fs there is patch which limits the
>>> number of retrie
Doron Shoham wrote:
> Hi,
>
> Why does the init script on suse re-discovers all iscsi targets which were set
> to automatic login?
> To avoid deadlocks on the root fs there is patch which limits the number of
> retries on first login.
> When doing so, it sets back all the default parameters (ove
> Also, what is the purpose of "node.startup" parameter?
> When is it in use?
>
Hi Mike,
Can you please explain this?
Thanks,
Doron
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to t
On Mon, Sep 22, 2008 at 9:39 AM, Hannes Reinecke <[EMAIL PROTECTED]> wrote:
>
> Hi Doron,
>
> Doron Shoham wrote:
>> Doron Shoham wrote:
>>> Hi,
>>>
>>> Why does the init script on suse re-discovers all iscsi targets which were
>>> set
>>> to automatic login?
>>> To avoid deadlocks on the root fs
Hi Doron,
Doron Shoham wrote:
> Doron Shoham wrote:
>> Hi,
>>
>> Why does the init script on suse re-discovers all iscsi targets which were
>> set
>> to automatic login?
>> To avoid deadlocks on the root fs there is patch which limits the number of
>> retries on first login.
>> When doing so, i
Doron Shoham wrote:
> Hi,
>
> Why does the init script on suse re-discovers all iscsi targets which were set
> to automatic login?
> To avoid deadlocks on the root fs there is patch which limits the number of
> retries on first login.
> When doing so, it sets back all the default parameters (ove
Hi,
Why does the init script on suse re-discovers all iscsi targets which were set
to automatic login?
To avoid deadlocks on the root fs there is patch which limits the number of
retries on first login.
When doing so, it sets back all the default parameters (overriding any user
definitions).
I
21 matches
Mail list logo
