Re: SCSI's heuristics for enabling WRITE SAME still need work [was: dm mpath: disable WRITE SAME if it fails]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/26/2013 04:42 PM, 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

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


--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux