On Sun, Aug 18, 2013 at 5:08 PM, Moussa Ba (moussaba)
<moussaba@xxxxxxxxxx> wrote:
> Our device is a high performance PCIe drive. aio is better.
I see.
The TGTD LUN, is it a normal LUN or have you activated thin-provisioning for it?
Can you compile tgtd from scratch and test?
If that is feasible, you can change usr/sbc.c and remove
WRITESAME10/16 completely from tgtd.
Towards the end of that file there is a definition of what commands
the emulated disk devices support :
static struct device_type_template sbc_template = {
...
Indices 0x41 and 0x93 refer to the two WRITESAME versions.
If you change these two lines :
{sbc_rw,}, /* WRITE_SAME10 */
...
{sbc_rw,}, /* WRITE_SAME_16 */
to instead be
{spc_illegal_op,},
Then WRITESAME10/16 will be disabled and you shouldnt get those
warnings in the logs.
I can try adding WRITESAME10/16 support to tgtd sometime in the next few days.
Would it be possible for you to test those patches for me ?
> Any plans for tgt to support ATS, full copy and other VAAI primitives?
Sure.
Do you have a list of which SCSI commands these refer to?
I assume COMPAREANDWRITE and XCOPY at least.
We have COMPAREANDWRITE in TGTD but it is not enabled by default.
Could you collect a wireshark trace and send to me so I can see what
the commands VMWARE sends looks like? If so I can give it a try to
implement something.
>
> Moussa
>
>
>
> -------- Original message --------
> From: ronnie sahlberg <ronniesahlberg@xxxxxxxxx>
> Date: 08/18/2013 17:04 (GMT-08:00)
> To: "Moussa Ba (moussaba)" <moussaba@xxxxxxxxxx>
> Cc: stgt@xxxxxxxxxxxxxxx
> Subject: Re: WRITE_SAME aio support
>
>
> If it is VMWARE then it probably uses WRITESAME10/16 for unmap/discard purposes.
>
> For now, can you try using bs_rdwr instead of bs_aio ?
>
>
> Longer term I will do a patch for
> * add WRITESAME10/16 + unmap support to bs_aio
> * make "indicate unmap support based on whether the backend supports it or not"
>
>
>
>
> On Sun, Aug 18, 2013 at 4:57 PM, Moussa Ba (moussaba)
> <moussaba@xxxxxxxxxx> wrote:
>> The LUN as seen by VMWare shows WRITE_SAME support. Not sure what is uses for discard
>>
>>
>> -------- Original message --------
>> From: ronnie sahlberg <ronniesahlberg@xxxxxxxxx>
>> Date: 08/18/2013 16:55 (GMT-08:00)
>> To: "Moussa Ba (moussaba)" <moussaba@xxxxxxxxxx>
>> Cc: stgt@xxxxxxxxxxxxxxx
>> Subject: Re: WRITE_SAME aio support
>>
>>
>> Your initiator uses WS10/16 for unmap/discard ?
>> (i.e. you mount the filesystem using -o discard in the guest)
>>
>> STGT currently offers "I support unmapping using both WS10 and 16". We
>> probably should only do this
>> for backends that supports these operations, == bs_rdwr.c and not
>> indicate support for the others.
>>
>>
>> What we probably need to do here is to make the support for
>> WRITESAME10/16 with unmap support optional
>> on whether the backend supports it.
>> I can look at adding this once I get some other changes in.
>>
>>
>>
>> On Wed, Aug 14, 2013 at 2:41 PM, Moussa Ba (moussaba)
>> <moussaba@xxxxxxxxxx> wrote:
>>> I am seeing a LOT of WRITE_SAME error messages in the tgt logs. I understand it is not implemented for aio, my question is will this affect array performance . We are using tgt to host datastores for a virtualization workload.
>>>
>>>
>>> tgtd: bs_aio_cmd_submit(211) WRITE_SAME not yet supported for AIO backend
>>>
>>>
>>> Moussa
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe stgt" in
>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe stgt" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe stgt" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
