On 6/29/23 08:40, Daniel Rozsnyó wrote: Please wrap your emails lines to under 80 chars. > > On 6/29/23 00:54, Bart Van Assche wrote: >> On 6/26/23 13:35, Daniel Rozsnyó wrote: >>> There are some drives, or more precisely - normal drives with a custom >>> firmware, that simply reject a regular Write - likely as not being good >>> enough for the intended high-rel application - which I can understand, >>> but even after reformatting the drive to no-PI and going to "poor" 512B >>> sector size, they still refuse to do an easy Write operation. I had >>> verified that by using the sg_write_verify (that uses an ioctl) I can >>> really write data to these drives. The reading path is working okay and >>> both dd and hdparm works at expected speeds. >> >> To me the above sounds like the drive firmware is broken. Please fix the >> drive firmware and make sure that WRITE commands are accepted. > > > It is not broken - it is by design. Or call it a feature (although it would > be nice to have a configurable flag that controls the rejection on the drive > side). > > > Same principle as is in place for more than a decade with server BIOSes (eg > from Supermicro) insisting on using ECC equipped memory - otherwise a > specific POST code happens and the machine wont start, even that non-ECC one > would be fine on the given CPU/IMC (and indeed does run on other brands). > > > (IRONY ON) If your approach is so "simple" - could you just "simply" ban from > Linux a complete lineup of 2 major hard drive vendors (Seagate, HGST), until > they do fix my particular firmware? Sure we do not want to support these > incompetent drive makers that ship drives with a potentially "broken" fw. > (IRONY OFF) > > > I could contact the vendors, but the firmware is not made for me - so I have > naturally no control over it. And the drive does not accept a firmware flash > to its own generic firmware family (now that I would say that went a bit too > far). > > > So could we at least find any reference from a T10 committee - how they > classify the WRITE command? > > - is it being a mandatory operation? Is that written in any SPC/SBC spec? > > > Oh - I did it: https://www.t10.org/lists/op-alph.htm and you wont be happy: > > The WRITE(10) is *OPTIONAL* for a Direct Access Block Device (SBC-4) All write commands are optional in SBC. > - so nope, the firmware which has no WRITE command is NOT broken according to > the T10 standards. > > > Lets get back to the original request/question then. What is the proper > approach to handle such command variation? 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 ? > > Daniel > -- Damien Le Moal Western Digital Research
