Douglas, > No, of course not. But the kernel should inspect all UAs especially > the one that says: CAPACITY DATA HAS CHANGED ! It does. And uses it to emit an event to userland. In most cases when capacity has changed it is because the user grew their LUN. And doing the right thing in that case is to let userland decide how to deal with it. You could argue that the kernel should do something if the device capacity shrinks. But it is unclear to me what "the right thing" is in all cases. What if there is not a mounted filesystem in the affected block range? Maybe the reduced block range it is not even described by an entry in the partition table? Should we do something? How does SCSI know how much of the capacity is actively in use, if any? Also, what's a partition? In addition, given our experience with NVMe devices which, for $OTHER_OS reasons, truncated their capacity when they experienced media problems, I am not sure we want to encourage anybody ever going down this path. What a mess! > Also more and more settings in SCSI *** are giving the option to > return an error (even MEDIUM ERROR) if the initiator is reading a > block that has never been written. So if the sd driver is looking for > a partition table (LBA 0 ?) then you have a chicken and egg problem > that retrying will not solve. For a general purpose OS it is completely unreasonable to expect that the OS has prior knowledge about which blocks were written. How is that even supposed to work if you plug in a USB drive from a different machine/OS? It also breaks the notion of array disks being self-describing which is now effectively an industry requirement. I am very happy to take patches that prevent us from retrying forever when a device is being disagreeable. But I am also very comfortable with the notion of not bothering to support devices that behave in a nonsensical way. Just because the SCSI spec allows something doesn't mean we should support it. > The sd driver should take its lead from SBC, not ZBC. The sd driver is the driver for both protocols. -- Martin K. Petersen Oracle Linux Engineering
