On Sun, 2020-12-06 at 13:53 +0800, Tom Yan wrote: > At least the SCSI disk driver is "benevolent" when it try to decide > whether the device actually supports write zeroes, i.e. unless the > device explicity report otherwise, it assumes it does at first. > > Therefore before we pile up bios that would fail at the end, we try > the command/request once, as not doing so could trigger quite a > disaster in at least certain case. For example, the host controller > can be messed up entirely when one does `blkdiscard -z` a UAS drive. > It's not as simple as that. There are some SCSI devices that support WRITE ZEROES, but do not return the MAXIMUM WRITE SAME LENGTH in the block device limits VPD page. So, some commands might work, and others might not. In particular, a commonly-used hypervisor does this. The sd driver disables the use of write same if certain errors are returned (INVALID COMMAND w/ INVALID COMMAND OPCODE or INVALID FIELD IN CDB), but if you do a blkdiscard -z of an entire drive a whole lot of bios/requests are already queued by the time you get that. Higher level code checks to see if write zeroes is supported, and won't queue the requests once it is turned off, but that doesn't happen until a command fails. We also check in command setup, see my earlier patch which deals with spurious blk_update_request errors if the disablement of write same gets detected there... I explicitly did not try to fix that by "testing" with one bio for the reason Christoph mentions. -Ewan
