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