>-----Original Message----- >From: Douglas Gilbert [mailto:dgilbert@xxxxxxxxxxxx] >Sent: Thursday, September 26, 2013 9:17 PM >To: Martin K. Petersen; Bernd Schubert >Cc: Mike Snitzer; Hannes Reinecke; emilne@xxxxxxxxxx; device-mapper >development; linux-scsi@xxxxxxxxxxxxxxx; Saxena, Sumit >Subject: Re: SCSI's heuristics for enabling WRITE SAME still need work >[was: dm mpath: disable WRITE SAME if it fails] > >On 13-09-26 10:42 AM, Martin K. Petersen wrote: >>>>>>> "Bernd" == Bernd Schubert <bernd.schubert@xxxxxxxxxxx> writes: >> >> Bernd, >> >> Bernd> Both types of systems we have in-house neither block limits vpd >> Bernd> nor READ_CAP16 return anything that would indicate discard is >> Bernd> supported. But UNMAP and WRITE SAME unmap(*) just work fine. >> >> I have a collection of different SSDs in a tray connected to an LSI >> SAS2008 ASIC. The 510 is the only drive that does not have LBPME=1. >> Chances are it's because DRAT and RZAT are not set but it could also >> be that the 510 is blacklisted. >> >> >> Bernd> I certainly don't want to cause any more write-same trouble, >> Bernd> but as all layers initially have to assume write same is >> Bernd> supported anyway and need to dynamically disable it if it >> Bernd> fails, can't we also enable discard by default with WRITE >SAME16 unmap? >> >> No thanks :) >> >> But you can force discards on by doing a: >> >> # echo -n unmap > /sys/class/scsi_disk/x:y:z:n/provisioning_mode >> >> or >> >> # echo -n writesame_16 > >> /sys/class/scsi_disk/x:y:z:n/provisioning_mode >> >> Create a udev rule if you like. >> >> In any case I wouldn't recommend using TRIM on that drive... >> >> >> Bernd> PS: LSI SATL with FWv17 seems to have an unmap bug - I cannot >> Bernd> unmap the last sector: >> >> Yes, it appears there's an off-by-one bug in the UNMAP translation. >> Sumit, is this something you guys can look into? > >Hi Sumit, >While you are looking at the HBA firmware could you fix this minor >annoyance: > Thibash, Can you please look at this? Sumit ># lsscsi -H -t >..... >[6] mpt3sas sas:0x500605b006d3b510 > ># smp_rep_general /dev/mpt3ctl -s 0x500605b006d3b510 Report general >response: > expander change count: 0 > expander route indexes: 0 > long response: 0 > number of phys: 0 > zone configuring: 0 > self configuring: 0 > externally configurable route table: 0 > initiates SSP close: 0 > enclosure logical identifier (hex): b005065010b5d306 > >So that is a SMP REPORT GENERAL (RG) directed at the HBA itself. >So either my code is incorrectly decoding the "enclosure logical >identifier" or ... . That field was defined in SAS 1.1 so no excuses on >that front. 0x0 would be better than a shuffled version of the HBA's own >SAS address. > >Same bug/feature in all versions of SAS-2 and now SAS-3 firmware that I >have tried. > >Doug Gilbert > > >BTW The bsg driver can send a RG to the HBA like this: > smp_rep_general /dev/bsg/sas_host6 > So the intent is clearer and the response is the same. > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
