[dm-devel] dm-mirror: do not degrade the mirror on discard error

[James Bottomley]

On Wed, 2015-02-18 at 12:10 -0500, Mike Snitzer wrote:
> On Wed, Feb 18 2015 at 11:29am -0500,
> Mikulas Patocka <mpatocka at redhat.com> wrote:
> 
> > 
> > 
> > On Wed, 18 Feb 2015, James Bottomley wrote:
> > 
> > > On Tue, 2015-02-17 at 14:59 -0500, Mikulas Patocka wrote:
> > > > 
> > > > On Mon, 16 Feb 2015, James Bottomley wrote:
> > > > 
> > > > > I already said this in the first sentence of the last paragraph of my
> > > > > email.  The point isn't what it does today it's what might happen
> > > > > tomorrow and the principle of least surprise.  One day, someone might
> > > > > propagate the error.  When that happens, they'll be surprised to find
> > > > > every discard failure reported as -ENOTSUPP and it will cost someone
> > > > > time and effort to investigate and fix.  If you just propagate the error
> > > > > today, you save all that work in the future.
> > > > > 
> > > > > James
> > > > 
> > > > The question is if this case is so important that it justifies dm-io 
> > > > change.
> > > 
> > > I'm not sure I follow.  Are you saying no-one would ever want to
> > > propagate the error?  I think that would be short sighted.
> > 
> > The SATA device may report success on the trim command and may not trim 
> > any data. I know this is stupid, but the standard allows the device to do 
> > that and the devices are doing that. See this thread 
> > http://www.spinics.net/lists/linux-scsi/msg80297.html
> > 
> > Consequently, if some filesystem or other application contains the logic 
> > "if trim succeeded, do something", it is broken, because the SSD may 
> > ignore the command and report success.
> > 
> > > > The SSD may ignore discards and report them as sucesfully completed, so no 
> > > > one should depend on the return code anyway. The error code may be used as 
> > > > a hint that it is futile to send more discards in the future, but relying 
> > > > on the return code is already not correct.
> > > 
> > > That's not a good way of interpreting the standards.
> > 
> > It doesn't matter how do you interpret the standard. It does matter how do 
> > SSD vendors interpret it. And they interpret it in such a way that it is 
> > OK to report success and not trim any data. I know it doesn't make much 
> > sense to standardize the flag "Return Zero After Trim" and then specify 
> > that the device (despite having RZAT set) may ignore the trim command and 
> > not return zeroes on the trimmed data. But it's the way it is.
> 
> Let's please set this thread to one side.  I already offered my thoughts
> in this thread, see: 
> https://www.redhat.com/archives/dm-devel/2015-February/msg00076.html
> 
> I'm not interested in wiring up the actual error return for dm-mirror's
> benefit.  If/when other dm-io consumers have a need to differentiate
> between error codes we'll fix dm-io as needed.

Yep, concur ... the point I've been obviously failing to make is that
all the world is not an SSD.

James