Thread (9 messages) 9 messages, 5 authors, 2021-11-10

Re: sorting out the freeze / quiesce mess

From: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: 2021-11-10 12:32:16
Also in: linux-nvme, linux-scsi

On Wed, 2021-11-10 at 11:22 +0100, Hannes Reinecke wrote:
On 11/10/21 10:14 AM, Christoph Hellwig wrote:
quoted
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

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help