Re: [linux-iscsi-devel] [question] deferred sense

[James Bottomley <James.Bottomley@SteelEye.com>]

On Wed, 2005-01-05 at 16:23 +0100, Christoph Hellwig wrote:
> On Wed, Jan 05, 2005 at 09:21:12AM -0600, Scott M. Ferris wrote:
> > To be more specific, there were some devices that would fail a command
> > and return deferred sense.  The command didn't complete at the target,
> > and the kernel wasn't retrying it because the sense was deferred
> > rather than current.  For those devices, the translation produced the
> > desired retry.
> 
> Do you remember these devices?  Might be worth adding a midlayer
> blacklist entry for them.

That's certainly possible ... although we'd need a lot more details.
Any device that returns deferred sense for a current error is pretty
badly broken according to the spec.

> And I suspect we should get linux-scsi in the loop for the discussion
> about deferred sense handling.

Well, I'm willing to think about it again, but beyond reporting to the
user that "something went wrong" I'm not sure there's anything we can
do.

The most common case for deferred sense is using a writeback cache.
Here the device takes the write into its cache and returns GOOD.  Later
trying to write it to the device it gets a medium error and now tries to
send deferred sense saying "you remember that write I told you worked,
well actually..."  by this time, we've already acknowledged the write to
the block layer and any JFS will proceed on the assumption that it
completed.  There's no way we can go back in time and apply this error
to an already completed transaction.  However, the device has violated
the journalling assumptions, and the FS will be corrupt.

So does anyone have any better suggestions for handling deferred sense?

James