On Wed, 2023-06-28 at 22:19 -0400, Martin K. Petersen wrote: > > Damien, > > > When scanning the drive, you need to poke it using > > scsi_report_opcode() to determine which write operation is > > supported. Then sd.c need to be modified to generate the proper > > write command if the regular WRITE 10/16/32 are not supported. You > > will also need to make sure that this does not break ATA drives > > managed with libata, so check libata-scsi translation. > > > > Not saying this can all be accepted though. But that is what is > > needed. > > > > Martin ? > > This is clearly a rare and special case, I have never come across a > drive that couldn't handle a regular WRITE command. > > I don't see any reason to burden our stack with workarounds for > drives that use custom firmware. I would also add that this seems to be arse backwards. If the intention is to have a high fidelity drive that always verifies writes, why not simply add a verify after every write in the firmware before completing the write? Even if you send a MISCOMPARE sense code back, we'll simply take it as write failure. If you do this in Firmware, the drive does what you want and is automatically supported by every current SCSI stack without modification (well there might be some where you'll have to give a failure sense code that WRITE would expect instead of MISCOMPARE). Regards, James
