All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Heinz Mauelshagen <heinzm@redhat.com>,
	Mike Snitzer <msnitzer@redhat.com>,
	dm-devel@redhat.com, "Alasdair G. Kergon" <agk@redhat.com>,
	Zdenek Kabelac <zkabelac@redhat.com>
Subject: Re: [PATCH] dm-mirror: do not degrade the mirror on discard error
Date: Wed, 18 Feb 2015 07:16:56 -0800	[thread overview]
Message-ID: <1424272616.2122.12.camel@HansenPartnership.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1502171455140.13128@file01.intranet.prod.int.rdu2.redhat.com>

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 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.  For instance unmap
has two types of error: permanent and transient.  Permanent means the
device would never be able to process the unmap and you should move on.
Transient means the device may be able to process the unmap and you
might like to repeat it.  Mostly the retries will be handled by SCSI but
not always.

That the discard issuer doesn't care is also not a given.  In the low
end SSD case you cite above, they probably don't.  However, if it's a
cloud environment charging per megabyte per day for provisioned
capacity, they probably do care.

The point here is that since you have the ability to do the right thing
(you have the error code the lower layer sent), just do it.  It will
save a lot of pain later on.  Doing the wrong thing and trying to
justify it post facto based on how you see the future evolving is
inevitably the wrong course of action because we're not very good at
predictions.

James

  reply	other threads:[~2015-02-18 15:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-12 15:09 [PATCH] dm-mirror: do not degrade the mirror on discard error Mikulas Patocka
2015-02-12 15:43 ` Mikulas Patocka
2015-02-15  2:39 ` James Bottomley
2015-02-15  3:36   ` Mike Snitzer
2015-02-16 12:44   ` [PATCH] " Mikulas Patocka
2015-02-16 14:27     ` James Bottomley
2015-02-17 19:59       ` Mikulas Patocka
2015-02-18 15:16         ` James Bottomley [this message]
2015-02-18 16:29           ` Mikulas Patocka
2015-02-18 17:10             ` Mike Snitzer
2015-02-18 17:54               ` James Bottomley
2015-02-18 18:21                 ` Mike Snitzer

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=1424272616.2122.12.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=heinzm@redhat.com \
    --cc=mpatocka@redhat.com \
    --cc=msnitzer@redhat.com \
    --cc=zkabelac@redhat.com \
    /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.