sorting out the freeze / quiesce mess

[James Bottomley]

On Wed, 2021-11-10 at 11:22 +0100, Hannes Reinecke wrote:
> On 11/10/21 10:14 AM, Christoph Hellwig wrote:
> > Hi Jens and Ming,
> > 
> > I've been looking into properly supporting queue freezing for bio
> > based
> > drivers (that is only release q_usage_counter on bio completion for
> > them).
> > And the deeper I look into the code the more I'm confused by us
> > having
> > the blk_mq_quiesce* interface in addition to
> > blk_freeze_queue.  What
> > is a good reason to do a quiesce separately from a freeze?
> > 
> IIRC the 'quiesce' interface was an abstraction from the SCSI
> 'quiesce'
> operation, where we had to stop all I/O except for TMFs and scanning.
> And 'freeze' was designed fro stopping all I/O.

Quiesce was a specific invention for SPI Domain Validation.  That's
where you try a specific set of patterns to the buffer and read them
back and try to jack up the transport parameters.  Pretty much every
transport does this type of retraining, but on all but SPI it's usually
hidden in hardware.

The point is you need to be able to stop all other I/O and then send
READ/WRITE_BUFFER commands to the device.

> But I'm not sure if that ever was the distinction, or if it still
> applies today.

As long as the SPI transport class exists, there'll be a distinction.
I'm not sure there's a use for quiesce beyond that.

> And yeah, I've been wondering myself.
> 
> Probably we should just kill the 'quiesce' stuff and see where we end
> up :-)

The SPI transport class would break.

James