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

From: Bernd Schubert <bernd.schubert@fastmail.fm>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: dgilbert@interlog.com, Mike Snitzer <snitzer@redhat.com>,
	Hannes Reinecke <hare@suse.de>,
	emilne@redhat.com,
	device-mapper development <dm-devel@redhat.com>,
	linux-scsi@vger.kernel.org, Sumit.Saxena@lsi.com
Subject: Re: SCSI's heuristics for enabling WRITE SAME still need work [was: dm mpath: disable WRITE SAME if it fails]
Date: Thu, 26 Sep 2013 17:34:07 +0200	[thread overview]
Message-ID: <524453EF.6040404@fastmail.fm> (raw)
In-Reply-To: <yq1r4cbablz.fsf@sermon.lab.mkp.net>

On 09/26/2013 04:42 PM, Martin K. Petersen wrote:
>>>>>> "Bernd" == Bernd Schubert <bernd.schubert@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