All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Christie <mchristi@redhat.com>
To: target-devel@vger.kernel.org
Subject: Re: [RFC PATCH] target: enable discard if supported by underlying block device
Date: Wed, 03 Jan 2018 18:33:32 +0000	[thread overview]
Message-ID: <5A4D21FC.2060101@redhat.com> (raw)
In-Reply-To: <20171219134517.17296-1-ddiss@suse.de>

On 12/19/2017 07:45 AM, David Disseldorp wrote:
> The initial commit of LIO (v4.0.0-rc6) came with support for SCSI UNMAP
> disabled. This was justified in the LIO wiki with:
>   Many SATA SSDs have issues handling UNMAP properly, so it is disabled
>   per default in LIO.
> Since this time, some critical discard bugs have been fixed, e.g.
> f3f5da624e0a ("block: Do a full clone when splitting discard bios").
> 
> Block layer backed logical units are capable of deferring to the block
> layer when determining UNMAP attributes, but this logic currently leaves
> the emulate_tpu (UNMAP) and emulate_tpws (WRITE_SAME with UNMAP=1) flags
> disabled.

Is there any cases where the user set tpu/tpws to off on purpose to
work around a backing device or initiator side issue? If so, I think the
only concern would be for non-rtslib based apps. If they did the attrib
setting stage after device creation but before the config stage, then
this patch would overwrite those settings.

For rtslib based apps, if the user had set tpu/tpws values to off on
purpose, it looks like the user requested values will still be used
since the attrib setting stage is done after the configure.

If we do not support non rtslib based apps then the patch is nice for
users and looks ok.

Reviewed-by: Mike Christie <mchristi@redhat.com>

  parent reply	other threads:[~2018-01-03 18:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-19 13:45 [RFC PATCH] target: enable discard if supported by underlying block device David Disseldorp
2018-01-03 12:25 ` David Disseldorp
2018-01-03 18:33 ` Mike Christie [this message]
2018-01-03 22:27 ` David Disseldorp
2018-01-13  5:13 ` Nicholas A. Bellinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5A4D21FC.2060101@redhat.com \
    --to=mchristi@redhat.com \
    --cc=target-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.