Re: A Data Integrity Negotiation Scheme for iSCSI

[Mark Bakke <mark.bakke@nuspeed.com>]

Rob-

Good point.  Perhaps if we were to negotiate the scheme, we
could negotiate the maximum "block" size covered by a data
integrity check as well.  The login might look like:

Login Request:

dataIntegrity: CRC32
dataIntegrityBlock: 8192
commandIntegrity: CRC32

Login Response:

dataIntegrity: CRC32
dataIntegrityBlock: 512
commandIntegrity: CRC32

The initiator would specify the largest block of data over
which any CRC could be used; the target could further limit
the size but could not request a larger size.  Both would
implicitly agree on the size sent by the target.  If the
initiator did not support the size specified by the target,
it could either give up, or try to log in using a different
data integrity scheme.

Another note - someone mentioned having data check tags
every once in a while to just make sure that the data stream
was still in sync; this is implicitly done when using a CRC
every so many bytes.  If one wanted a scheme without CRC
overhead, but with a sync check, one could negotiate a scheme
of SYNC32, and place a magic number instead of the CRC; if the
magic number was wrong, data errors affecting length fields
would be assumed, and the connection would be re-started.

Request:

dataIntegrity: SYNC32
dataIntegrityBlock: 4096
dataIntegrityMagic: 0x00c0ffee

Response:

dataIntegrity: SYNC32
dataIntegrityBlock: 4096
dataIntegrityMagic: 0x00c0ffee

Subsequent data would include the magic number "0x00c0ffee"
after every 4k bytes for both read and write requests.

The above could also be done by just doing CRC on commands,
and no CRC on the data, but a sync check would allow this
do be done on a block-by-block basis, which as you said, may
be implemented in a device with relatively minimal buffering.

At any rate, the data integrity negotiation scheme should
be extensible enough to add these things.

--
Mark

Robert Elliott wrote:
> 
> Mark A Bakke wrote:
> > The CRC32 Scheme
> >
> >   Other than "none", "CRC32" is the scheme specified in this
> >   document.  Other schemes that may be more applicable should
> >   be proposed as well.
> >
> >   If the CRC32 scheme is negotiated for headers, a 32-bit CRC
> >   is at the end of an iSCSI request or response, or between
> >   the request and its data, as described above.
> >
> >   If the CRC32 scheme is negotiated for data, a 32-bit CRC
> >   is added to the end of all data, covering ONLY the data (headers
> >   and commands sold separately).
> >
> >   The big open question here is whether to support a CRC at the
> >   end of the data request, or at the end of every [8k?] "block"
> >   of data, or both.  The advantage of a CRC over just the block
> >   is simplicity; this works fine for most block device accesses,
> >   since file systems and databases usually write in 2, 4, or 8k
> >   clusters.  However, if the data is of sufficient size as to make
> >   the check too weak (tape backup software and specialized file
> >   systems for large block data can write 64k .. 1MB or more at
> >   a time), we would need to add the CRC more often.
> 
> Storage devices cannot commit data to storage until the CRC has been
> checked, so larger intervals imply larger temporary storage buffers.
> In parallel SCSI (Ultra 3) the target was given the ability to choose
> how often CRC is transferred for both writes and reads.  This keeps
> it from needing infinite buffers for writes - if it has a 512 byte
> write buffer, it can ask for a CRC every 512 bytes.  For reads, the
> initiator can just redo the read if an error is detected - nothing
> disastrous happens if bad data enters its destination buffer before
> the command is marked complete.  The target can send CRC when it
> chooses.
> 
> --
> Rob Elliott      UNIX mailto:relliott@hobbit.eng.hou.compaq.com
> Houston, TX        PC mailto:Robert.Elliott@compaq.com

-- 
Mark A. Bakke
NuSpeed, Inc.
mark.bakke@nuspeed.com
763.398.1054