FCP_RSP Residual Checking.

Robert Snively rsnively at Brocade.COM
Tue Jul 10 16:35:19 PDT 2001


* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at brocade.com>
*
Implicit in the original statement about which I was
commenting was something like:

	Write 2000 blocks
		(The device and OS disagree on the length of
		blocks, so the disk actually writes 2000 500 byte
		blocks, while the FCP_DL was set for 2000 512 byte
		blocks)

		Response will be 2000 X 12 bytes not sent.

	Write the last 24000 bytes again, because they were
		not written the first time.

This is not what the residue means or how it should be interpreted.

Another case would be 

	Write 2000 blocks

		The device has a write safety check halfway through
		the write and stops writing after 1000 blocks.  However,
		the FCP has cheerfully been stuffing buffer up to
		1500 blocks.  The CHECK CONDITION says that the
		1001st block failed, but the residue says that
		500 blocks were not transmitted.

	Write retry should probably be all 2000 blocks, since
		write safety is bad enough to indicate that maybe
		vibrations had bothered other blocks.  In any case,
		even if you trusted the drive, you should look at the
		sense information and start writing at block 1001, not
		at the residue and start writing at block 1501.

This is again, not what the residue means or how it should be 
interpreted.

-----Original Message-----
From: Matthew Jacob [mailto:mjacob at feral.com]
Sent: Monday, July 09, 2001 10:27 AM
To: Robert Snively
Cc: 'Pat LaVarre'; t10 at t10.org
Subject: RE: FCP_RSP Residual Checking.



Bob, you write:

> Therefore,
>
>    a)	The hosts can never retry based on residue.  They must
> 	use CHECK CONDITION information.


Can you clarify this a bit? Do you mean below the host driver stack?

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list