Re: [storm] Removing iSCSI Markers?

William Stouder-Studenmund <> Tue, 30 March 2010 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 243833A6891 for <>; Tue, 30 Mar 2010 10:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.468
X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EkoPHPjet0OH for <>; Tue, 30 Mar 2010 10:07:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D81A03A67A5 for <>; Tue, 30 Mar 2010 10:07:55 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_seqIWNj+zpQF2jtkQwqDCQ)"
Received: from [] by (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <> for; Tue, 30 Mar 2010 10:08:08 -0700 (PDT)
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003300164
From: William Stouder-Studenmund <>
In-reply-to: <>
Date: Tue, 30 Mar 2010 10:03:05 -0700
Message-id: <>
References: <> <> <SNT131-ds389E5D120CA34D81D341FA01F0@phx.gbl> <> <SNT129-W39116021288D2177842E5DE61F0@phx.gbl> <>
To: Paul Koning <>
X-Mailer: Apple Mail (2.1141)
Subject: Re: [storm] Removing iSCSI Markers?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Mar 2010 17:08:02 -0000

On Mar 30, 2010, at 7:22 AM, Paul Koning wrote:

> Thanks Asgeir.
> As I recall, the original idea behind markers is to make it possible to build 10G HBAs that can run at wire speed, which was believed to be impossible otherwise.

I obviously came late to iSCSI when I started. That's _not_ what I thought markers were for. I thought they were to support within-connection error recover. I saw no other way to recover from a header digest error otherwise. Well, within the connection.

Back when it existed, the Wasabi target handled marker generation. I don't think we ever got around to adding the error recovery that would use it, but it was planned.

Take care,


> The subsequent record indicates that this was in fact not the case; 10G HBAs are feasible and have been built without resorting to markers.  There is no other reason for using markers.  So if the one reason that they were thought to be needed in fact turned out not to be real, the obvious thing to do is to remove the unused complications from the spec.
> I suppose one could argue that, placed in an appendix and “optional to implement” they do no harm.  That’s a fair point.  If there is still a chance that they will turn out to be needed in the future we may want to go that way.  I personally would bet against that chance.