From: Andrew McGregor <andrew@indranet.co.nz>
To: Oliver Xymoron <oxymoron@waste.org>
Cc: Roman Zippel <zippel@linux-m68k.org>, linux-kernel@vger.kernel.org
Subject: Re: Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)
Date: Wed, 08 Jan 2003 00:24:24 +1300 [thread overview]
Message-ID: <2340000.1041938664@localhost.localdomain> (raw)
In-Reply-To: <20030107042045.GA10045@waste.org>
No no, that's a 1% chance that one packet in the terabyte is broken.
But actually, it's not that hard to construct a peturbation to the packet
that will beat both the ethernet and TCP checksums (I gave an example that
beats TCP before). That kind of change is not likely for random bit
errors, but is quite likely to occur in just slightly marginal hardware.
Partial packet duplication or byte reordering on the highly ordered data
patterns you find in filesystem metadata could be really bad.
Like I say, debugging one crypto protocol I've seen this happen for real.
Twice in about 10000 packets, on an otherwise apparently perfectly fine
LAN. I suspect bad cabling, and changed it, but it's hard to tell that
anything has changed. That shows that my 1% is probably quite conservative
for that particular link.
Internet protocols (changing to IETF hat now) are supposed to work on the
global internet, and that means iSCSI has to be engineered to work on the
worst links imaginable, because sometime, somewhere, someone's data is
going to cross a really broken backup link that they have no way of knowing
has just come on. Possibly it's wireless, where packet corruption due to
undetected collisions happens quite frequently.
Andre routinely tests it with the IBM team in Israel, with his end in
California.
Andrew
--On Monday, January 06, 2003 22:20:46 -0600 Oliver Xymoron
<oxymoron@waste.org> wrote:
> On Tue, Jan 07, 2003 at 01:39:38PM +1300, Andrew McGregor wrote:
>> Hmm. The problem here is that there is a nontrivial probability that a
>> packet can pass both ethernet and TCP checksums and still not be right,
>> given the gigantic volumes of data that iSCSI is intended to be used
>> with. Back up a 100 terabyte array and it's more than 1%, back of the
>> envelope.
>
> What was the underlying error rate and distribution you assumed? I
> figure if it were high enough to get to your 1%, you'd have such high
> retry rates (and resulting throughput loss) that the operator would
> notice his LAN was broken weeks before said transfer completed.
>
> --
> "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
>
>
next prev parent reply other threads:[~2003-01-07 11:21 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-05 1:54 Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!) Andre Hedrick
2003-01-05 2:47 ` Andrew Morton
2003-01-05 3:26 ` NEURONET
2003-01-05 4:11 ` NEURONET
2003-01-05 4:41 ` Andre Hedrick
2003-01-05 6:16 ` Andrew Morton
2003-01-06 3:06 ` Oliver Xymoron
2003-01-06 3:38 ` Andre Hedrick
2003-01-06 5:24 ` Oliver Xymoron
2003-01-06 10:24 ` Andrew McGregor
2003-01-06 16:51 ` Roman Zippel
2003-01-07 0:28 ` Andre Hedrick
2003-01-07 20:36 ` Roman Zippel
2003-01-07 22:45 ` Andre Hedrick
2003-01-08 0:04 ` Roman Zippel
2003-01-08 1:43 ` Alan Cox
2003-01-08 1:08 ` Larry McVoy
2003-01-08 16:48 ` Vojtech Pavlik
2003-01-08 19:37 ` Andre Hedrick
2003-01-07 0:39 ` Andrew McGregor
2003-01-07 4:20 ` Oliver Xymoron
2003-01-07 5:38 ` Valdis.Kletnieks
2003-01-07 6:16 ` Werner Almesberger
2003-01-07 6:43 ` Valdis.Kletnieks
2003-01-07 7:08 ` Werner Almesberger
2003-01-07 8:00 ` Valdis.Kletnieks
2003-01-07 8:14 ` Werner Almesberger
2003-01-07 8:41 ` Valdis.Kletnieks
2003-01-07 17:07 ` Werner Almesberger
2003-01-07 12:12 ` Andrew McGregor
2003-01-07 6:45 ` Lincoln Dale
2003-01-07 7:02 ` Valdis.Kletnieks
2003-01-07 11:24 ` Andrew McGregor [this message]
2003-01-07 10:31 ` Olivier Galibert
2003-01-08 19:10 ` H. Peter Anvin
2003-01-08 20:09 ` Andrew McGregor
2003-01-08 20:40 ` Richard B. Johnson
2003-01-07 12:31 ` Alan Cox
2003-01-07 12:31 ` Andrew McGregor
2003-01-07 13:58 ` Alan Cox
2003-01-07 23:09 ` Andrew McGregor
2003-01-07 16:21 ` Oliver Xymoron
2003-01-07 13:04 ` Lionel Bouton
[not found] ` <Pine.LNX.4.10.10301051924140.421-100000@master.linux-ide.o rg>
2003-01-06 7:14 ` Lincoln Dale
2003-01-06 7:53 ` Linux iSCSI Initiator Andre Hedrick
[not found] ` <Pine.LNX.4.10.10301052337150.421-100000@master.linux-ide.o rg>
2003-01-06 9:10 ` Lincoln Dale
2003-01-06 9:28 ` Andre Hedrick
2003-01-06 3:25 ` Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!) Richard Stallman
2003-01-06 4:08 ` Andre Hedrick
2003-01-06 20:49 ` Richard Stallman
-- strict thread matches above, loose matches on Subject: below --
2003-01-05 22:51 Adam J. Richter
[not found] <fa.kccjmvv.13go3jp@ifi.uio.no>
[not found] ` <fa.hjtum4v.fki8p1@ifi.uio.no>
2003-01-08 1:07 ` walt
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=2340000.1041938664@localhost.localdomain \
--to=andrew@indranet.co.nz \
--cc=linux-kernel@vger.kernel.org \
--cc=oxymoron@waste.org \
--cc=zippel@linux-m68k.org \
/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