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, but
Bernd> as all layers initially have to assume write same is supported
Bernd> anyway and need to dynamically disable it if it fails, can't we
Bernd> 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:
# 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.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
