On 09/26/2013 04:42 PM, Martin K. Petersen wrote:
"Bernd" == Bernd Schubert <bernd.schub...@fastmail.fm> 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
D'oh, I didn't know about this parameter! THANKS a lot!
Create a udev rule if you like.
Definitely, we have rules anyway.
In any case I wouldn't recommend using TRIM on that drive...
Hmm yeah, the problem is that that these SSDs are used in our compute
nodes (but we as file system group can also sometimes use it for
benchmarking) and these SSDs slow down rather quickly without trim. The
current procedure is to remove everything, to sg_unmap the full device
and to re-create anything. So anything that would allow us to do it on
the fly is very welcome. I don't think we need DRAT and RZAT, as we only
use raid0 for these nodes.
So thanks a lot for your hint about the provisioning_mode!
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?
Thanks again,
Bernd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
