Drive reset as an EH strategy when write cache is enabled

Drive reset as an EH strategy when write cache is enabled

[Phillip Susi]

A while back I noticed lines in my syslog indicating that a FLUSH CACHE
command timed out and the drive was hard reset to recover.  That made me
wonder if such a thing makes any sense as a valid EH strategy.  Any
previous writes that returned successfully but are still sitting in the
drive's write cache will be silently invalidated by resetting the drive
won't they?  Then the FLUSH CACHE command is retried, and of course,
succeeds because it is now a NOOP.  Then fsync() returns and postfix
thinks my new email has been committed to the disk, when in fact, it has
not.

Am I mistaken somewhere or is the kernel really doing the wrong thing
here?

Re: Drive reset as an EH strategy when write cache is enabled

[Christoph Hellwig]

On Tue, Dec 01, 2020 at 12:24:50PM -0500, Phillip Susi wrote:
> A while back I noticed lines in my syslog indicating that a FLUSH CACHE
> command timed out and the drive was hard reset to recover.  That made me
> wonder if such a thing makes any sense as a valid EH strategy.  Any
> previous writes that returned successfully but are still sitting in the
> drive's write cache will be silently invalidated by resetting the drive
> won't they?  Then the FLUSH CACHE command is retried, and of course,
> succeeds because it is now a NOOP.  Then fsync() returns and postfix
> thinks my new email has been committed to the disk, when in fact, it has
> not.
> 
> Am I mistaken somewhere or is the kernel really doing the wrong thing
> here?

If the device drops the content of the volatile write on a reset we'll
have much problems than that..

Re: Drive reset as an EH strategy when write cache is enabled

[Phillip Susi]

Christoph Hellwig writes:

> If the device drops the content of the volatile write on a reset we'll
> have much problems than that..

How could it not?  The write cache is empty after a power on reset and
certainly a "hard" reset should be the same as a power on reset.

Re: Drive reset as an EH strategy when write cache is enabled

[James Bottomley]

On Wed, 2020-12-02 at 10:55 -0500, Phillip Susi wrote:
> Christoph Hellwig writes:
> 
> > If the device drops the content of the volatile write on a reset
> > we'll have much problems than that..
> 
> How could it not?  The write cache is empty after a power on reset
> and certainly a "hard" reset should be the same as a power on reset.

As Christoph said it would be stupid behaviour to invalidate the cache
after a hard reset because it would cause all deferred writes to fail. 
The SCSI standards committee did initially assume manufacturers knew
this, but it was codified in SBC-4 and beyond with an explicit list of
conditions under which the write back cache could be lost, which
doesn't include hard reset.

James

Re: Drive reset as an EH strategy when write cache is enabled

[Phillip Susi]

James Bottomley writes:

> As Christoph said it would be stupid behaviour to invalidate the cache
> after a hard reset because it would cause all deferred writes to fail. 
> The SCSI standards committee did initially assume manufacturers knew
> this, but it was codified in SBC-4 and beyond with an explicit list of
> conditions under which the write back cache could be lost, which
> doesn't include hard reset.

Wow... so a hard reset is in fact, not really a hard reset?  I can see a
soft reset maybe preserving the cache but I would expect a hard reset to
be equal to pulsing the ^RST line.  In fact, my understanding from
reading the SATA spec was that the hard reset bus condition was intended
to be detected by the PHY layer and pulse the ^RST signal to the higher
level logic.  Wait... SBC-4 applies to ATA disks too?