On Thu, Jun 06, 2024 at 07:52:51AM -0700, Christoph Hellwig wrote: > On Thu, Jun 06, 2024 at 10:30:06PM +0800, Ming Lei wrote: > > Yeah, that is one area queue freezing can't cover logical block size > > change, but I'd suggest to put the logical bs check into submit_bio() or > > slow path of __bio_queue_enter() at least. > > We really need an alignment check in submit_bio anyway, so doing it > under the freeze protection would also help with this. > > > My concern is that nvme format is started without draining IO, and > > IO can be submitted to hardware when nvme FW is handling formatting. > > I am not sure if nvme FW can deal with this situation correctly. > > Ewan suggested to run 'nvme format' with exclusive nvme disk open, which > > needs nvme-cli change. > > .. and doesn't protect against someone using a different tool anyway. It also doesn't work if format is sent from a different host. If you have a shared namespace, anyone could change the format without coordinating with anyone else. That's just an unfixable gap with the current spec. The driver tries to react to the Namespace Notice AEN for this, but that can be too late or not even enabled. > That beeing said, nvme_passthru_start actually freezes all queues > based on the commands supported an affects log, and > nvme_init_known_nvm_effects should force this even for controllers > not supporting the log or reporting bogus information. So in general > the queue should be frozen during the actual format. Just for single host consideration, the our current nvme freeze does ensure IO is drained before dispatching the format, and should work for most format changes.
