On Mon, Apr 25, 2022 at 07:10:46AM +0200, Greg Kroah-Hartman wrote: > > But what is wrong with the test? Isn't it reasonable to keep debugfs dir > > when blktrace is collecting log? > > How can you collect something from a device that is gone? > > > After debugfs dir is removed, blktrace may not collect intact log, and > > people may complain it is one kernel regression. > > What exactly breaks? The device is removed, why should a trace continue > to give you data? This is a good question. All but one of the block device drivers really only have a concept of a block "queue" that is attached to a live block device. In that case the awnser is simple and obvious. But SCSI allocates these queues before the block device, and they can outlive it, because SCSI is a layered architecture where the "upper level" drivers like sd and st are only bound to the queue based on information returned from it, and the queue can outlive unbinding these drivers (which is a bit pointless but possible due to full device model integration). So there might be some uses cases to keep on tracing. I don't think they are very valid, though, because if you really want to trace that raw queue you can do it using the /dev/sg node.
