On Dec 7 2010, 11:12 pm, Mike Christie <[email protected]> wrote:
> It could, but you should be ok. If the notification that the connection
> is dead comes after IO is sent then we would try to send IO to the
> network layer, but the iscsi layer would eventually figure things out
> and end up resending the IO after it has reconnected to the target.
Hi list (my first post here).
I'm an iscsi noob (just bought a cheap NAS) and just succeeded in
moving
an existing Debian install to a diskless, PXE & root-on-iscsi setup.
It works fine, except for the subject of this thread: when resuming
from
ram suspend (and probably after waiting long enough in suspend, I
haven't
done many tries so far), resume is stuck for 120s (
node.session.timeo.replacement_timeout is set to 120s by default,
maybe
this is the timeout I encounter), then a reconnection occurs and
resume
finishes successfully. Though not without emitting a handful of kernel
BUGs ("soft lockup - CPU#0 stuck for 22s").
For the moment, I don't have an idea on how to make resume happen
gracefully:
- Shorten this timeout ? But for what risks ? Network setup is
dead-simple: Gb ethernet with one switch and a few meters of cable.
- I found a dmsetup suspend command, but I'm not sure I want to run
this
on a root device...
- Get some script to be cached before suspend and executed early upon
resume ?
Any pointer welcome.
Regards,
--
Vincent Pelletier
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
