From: Dmitry Yusupov <dmitry_yus@yahoo.com>
To: "open-iscsi@googlegroups.com" <open-iscsi@googlegroups.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>,
mpm@selenic.com, andrea@suse.de,
James.Bottomley@HansenPartnership.com,
ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com
Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics
Date: Sun, 27 Mar 2005 13:49:11 -0800 [thread overview]
Message-ID: <1111960151.5824.41.camel@mylaptop> (raw)
In-Reply-To: <20050327103115.5c746472.davem@davemloft.net>
On Sun, 2005-03-27 at 10:31 -0800, David S. Miller wrote:
> On Sun, 27 Mar 2005 10:26:29 -0800
> Mike Christie <michaelc@cs.wisc.edu> wrote:
>
> > reliable receive is ciritical for WRITEs. Even if the WRITE is executed
> > successfully on the remote device, if we cannot receive the return status
> > from the device the operation will fail at the iscsi driver side due to a
> > SCSI timeout.
>
> I keep hearing this word "reliable", it means something very
> different for TCP over a transport like IP than it does
> for the SCSI layer.
>
> It is, in fact, the whole difficulty of implementing iSCSI:
> being able to cope with this difference in expectations.
actually, you absolutely right!
there are two ways to achieve reasonable "reliability" of iSCSI
transport:
1) ERL=2(see RFC3720) + multiple connections (read: single iSCSI session
with multiple connections)
2) ERL=0 + device multipath (read: multiple iSCSI sessions with single
connection per session)
I think we should slow down on "reliability" feature since 1) and 2)
basically covers the case. All we need is to make sure that deadlock
situations during OOM will never happen.
> All I can see is that the SCSI layer's timeout is inappropriate
> for something like iSCSI, not that TCP or networking needs
> to change in some way.
right. looks like there is the way to "postpone" SCSI timeout until
iSCSI session will finally recover.
next prev parent reply other threads:[~2005-03-27 21:49 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4241D106.8050302@cs.wisc.edu>
[not found] ` <20050324101622S.fujita.tomonori@lab.ntt.co.jp>
[not found] ` <1111628393.1548.307.camel@beastie>
[not found] ` <20050324113312W.fujita.tomonori@lab.ntt.co.jp>
[not found] ` <1111633846.1548.318.camel@beastie>
[not found] ` <20050324215922.GT14202@opteron.random>
[not found] ` <424346FE.20704@cs.wisc.edu>
[not found] ` <20050324233921.GZ14202@opteron.random>
[not found] ` <20050325034341.GV32638@waste.org>
[not found] ` <20050327035149.GD4053@g5.random>
2005-03-27 5:48 ` [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics Matt Mackall
2005-03-27 6:04 ` Andrea Arcangeli
2005-03-27 6:38 ` Matt Mackall
2005-03-27 14:50 ` Andrea Arcangeli
2005-03-27 6:33 ` Dmitry Yusupov
2005-03-27 6:46 ` David S. Miller
2005-03-27 7:05 ` Dmitry Yusupov
2005-03-27 7:57 ` David S. Miller
2005-03-27 8:18 ` Dmitry Yusupov
2005-03-27 18:26 ` Mike Christie
2005-03-27 18:31 ` David S. Miller
2005-03-27 19:58 ` Matt Mackall
2005-03-27 21:49 ` Dmitry Yusupov [this message]
2005-03-27 18:47 ` Dmitry Yusupov
2005-03-27 21:14 ` Alex Aizman
[not found] ` <20050327211506.85EDA16022F6@mx1.suse.de>
2005-03-28 0:15 ` Andrea Arcangeli
2005-03-28 3:54 ` Rik van Riel
2005-03-28 4:34 ` David S. Miller
2005-03-28 4:50 ` Rik van Riel
2005-03-28 6:58 ` Alex Aizman
2005-03-28 16:12 ` Andi Kleen
2005-03-28 16:22 ` Andrea Arcangeli
2005-03-28 16:24 ` Rik van Riel
2005-03-29 15:11 ` Andi Kleen
2005-03-29 15:29 ` Rik van Riel
2005-03-29 17:03 ` Matt Mackall
2005-03-28 16:28 ` James Bottomley
2005-03-29 15:20 ` Andi Kleen
2005-03-29 15:56 ` James Bottomley
2005-03-29 17:19 ` Dmitry Yusupov
2005-03-29 21:08 ` jamal
2005-03-29 22:00 ` Rik van Riel
2005-03-29 22:17 ` Matt Mackall
2005-03-29 23:30 ` jamal
2005-03-29 23:00 ` jamal
2005-03-29 23:25 ` Matt Mackall
2005-03-30 0:30 ` H. Peter Anvin
2005-03-30 15:24 ` Andi Kleen
2005-03-29 22:03 ` Rick Jones
2005-03-29 23:13 ` jamal
2005-03-30 2:28 ` Alex Aizman
[not found] ` <E1DGSwp-0004ZE-00@thunker.thunk.org>
2005-03-30 17:16 ` Grant Grundler
2005-03-30 18:46 ` Dmitry Yusupov
2005-03-30 15:22 ` Andi Kleen
2005-03-30 15:33 ` Andrea Arcangeli
2005-03-30 15:38 ` Rik van Riel
2005-03-30 15:39 ` Andi Kleen
2005-03-30 15:44 ` Andrea Arcangeli
2005-03-30 15:50 ` Rik van Riel
2005-03-30 16:04 ` James Bottomley
2005-03-30 17:48 ` H. Peter Anvin
2005-03-30 16:02 ` Andi Kleen
2005-03-30 16:15 ` Andrea Arcangeli
2005-03-30 16:55 ` jamal
2005-03-30 18:42 ` Rik van Riel
2005-03-30 19:28 ` Alex Aizman
2005-03-31 11:41 ` Andi Kleen
2005-03-31 12:12 ` Rik van Riel
2005-03-31 18:59 ` Andi Kleen
2005-03-31 19:04 ` Rik van Riel
2005-03-31 15:35 ` Grant Grundler
2005-03-31 19:15 ` Alex Aizman
2005-03-31 19:34 ` Andi Kleen
2005-03-31 19:39 ` Rik van Riel
2005-03-31 11:45 ` Andi Kleen
2005-03-31 11:50 ` Andi Kleen
2005-03-31 17:09 ` Andrea Arcangeli
2005-03-31 22:05 ` Dmitry Yusupov
2005-03-30 17:24 ` Matt Mackall
2005-03-30 17:39 ` Dmitry Yusupov
2005-03-30 20:10 ` Mike Christie
2005-03-30 17:07 ` Grant Grundler
2005-03-30 5:12 ` H. Peter Anvin
2005-03-28 16:37 ` Dmitry Yusupov
2005-03-28 19:45 ` Roland Dreier
2005-03-28 20:32 ` Topic: Remote DMA network technologies Gerrit Huizenga
2005-03-28 20:36 ` Roland Dreier
[not found] ` <1112042936.5088.22.camel@beastie>
2005-03-28 22:32 ` [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics Benjamin LaHaise
2005-03-29 3:19 ` Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Roland Dreier
2005-03-30 16:00 ` Benjamin LaHaise
2005-03-31 1:08 ` Linux support for RDMA H. Peter Anvin
2005-04-02 18:08 ` [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics Dmitry Yusupov
2005-04-02 19:13 ` Ming Zhang
2005-04-04 6:31 ` Grant Grundler
2005-04-04 18:57 ` Rick Jones
2005-03-29 3:14 ` Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Roland Dreier
[not found] <42472259.2866086e.3169.318fSMTPIN_ADDED@mx.googlegroups.com>
2005-03-27 21:18 ` [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics Alex Aizman
2005-03-27 21:53 Alex Aizman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1111960151.5824.41.camel@mylaptop \
--to=dmitry_yus@yahoo.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=andrea@suse.de \
--cc=ksummit-2005-discuss@thunk.org \
--cc=michaelc@cs.wisc.edu \
--cc=mpm@selenic.com \
--cc=netdev@oss.sgi.com \
--cc=open-iscsi@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).