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