linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans Holmberg <hans@owltronix.com>
To: Igor Konopko <igor.j.konopko@intel.com>
Cc: "Matias Bjorling" <mb@lightnvm.io>,
	"Javier González" <javier@javigon.com>,
	"Hans Holmberg" <hans.holmberg@cnexlabs.com>,
	linux-block@vger.kernel.org
Subject: Re: [PATCH 14/18] lightnvm: pblk: GC error handling
Date: Mon, 18 Mar 2019 15:14:21 +0100	[thread overview]
Message-ID: <CANr-nt0CRVfWzJBDJD8P6zmC9VRPFDWKs-1Ueem64mN2cNFePA@mail.gmail.com> (raw)
In-Reply-To: <c97739cf-df61-f6d4-7735-78e5743d0c1f@intel.com>

On Mon, Mar 18, 2019 at 2:22 PM Igor Konopko <igor.j.konopko@intel.com> wrote:
>
>
>
> On 18.03.2019 13:14, Hans Holmberg wrote:
> > On Thu, Mar 14, 2019 at 5:09 PM Igor Konopko <igor.j.konopko@intel.com> wrote:
> >>
> >> Currently when there is an IO error (or similar) on GC read path, pblk
> >> still moves this line to free state, what leads to data mismatch issue.
> >>
> >> This patch adds a handling for such an error - after that changes this
> >> line will be returned to closed state so it can be still in use
> >> for reading - at least we will be able to return error status to user
> >> when user tries to read such a data.
> >>
> >> Signed-off-by: Igor Konopko <igor.j.konopko@intel.com>
> >> ---
> >>   drivers/lightnvm/pblk-core.c | 8 ++++++++
> >>   drivers/lightnvm/pblk-gc.c   | 5 ++---
> >>   drivers/lightnvm/pblk-read.c | 1 -
> >>   drivers/lightnvm/pblk.h      | 2 ++
> >>   4 files changed, 12 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/lightnvm/pblk-core.c b/drivers/lightnvm/pblk-core.c
> >> index 4d5cd99..6817f8f 100644
> >> --- a/drivers/lightnvm/pblk-core.c
> >> +++ b/drivers/lightnvm/pblk-core.c
> >> @@ -1786,6 +1786,14 @@ static void __pblk_line_put(struct pblk *pblk, struct pblk_line *line)
> >>
> >>          spin_lock(&line->lock);
> >>          WARN_ON(line->state != PBLK_LINESTATE_GC);
> >> +       if (line->w_err_gc->has_gc_err) {
> >> +               spin_unlock(&line->lock);
> >> +               pblk_err(pblk, "line %d had errors during GC\n", line->id);
> >> +               pblk_put_line_back(pblk, line);
> >> +               line->w_err_gc->has_gc_err = 0;
> >
> > In a real bummer corner case, the line might have had a write error as well
> > (line->w_err_gc->has_write_err == true)
> >
> > In that case we need to inform the rate limiter:
> > pblk_rl_werr_line_out(&pblk->rl);
>
> Is that needed or rather preferred?
>
> I'm not clearing w_err_gc->has_write_err value in that case (and thus
> not informing the rate limiter), so the line will go back to exactly the
> same state as before GC (still with write error marked).

You're right, we will try to gc the line again. Thanks!

Reviewed-by: Hans Holmberg <hans.holmberg@cnexlabs.com>

>
> >
> >> +               return;
> >> +       }
> >> +
> >>          line->state = PBLK_LINESTATE_FREE;
> >>          trace_pblk_line_state(pblk_disk_name(pblk), line->id,
> >>                                          line->state);
> >> diff --git a/drivers/lightnvm/pblk-gc.c b/drivers/lightnvm/pblk-gc.c
> >> index e23b192..63ee205 100644
> >> --- a/drivers/lightnvm/pblk-gc.c
> >> +++ b/drivers/lightnvm/pblk-gc.c
> >> @@ -59,7 +59,7 @@ static void pblk_gc_writer_kick(struct pblk_gc *gc)
> >>          wake_up_process(gc->gc_writer_ts);
> >>   }
> >>
> >> -static void pblk_put_line_back(struct pblk *pblk, struct pblk_line *line)
> >> +void pblk_put_line_back(struct pblk *pblk, struct pblk_line *line)
> >>   {
> >>          struct pblk_line_mgmt *l_mg = &pblk->l_mg;
> >>          struct list_head *move_list;
> >> @@ -98,8 +98,7 @@ static void pblk_gc_line_ws(struct work_struct *work)
> >>          /* Read from GC victim block */
> >>          ret = pblk_submit_read_gc(pblk, gc_rq);
> >>          if (ret) {
> >> -               pblk_err(pblk, "failed GC read in line:%d (err:%d)\n",
> >> -                                                               line->id, ret);
> >> +               line->w_err_gc->has_gc_err = 1;
> >>                  goto out;
> >>          }
> >>
> >> diff --git a/drivers/lightnvm/pblk-read.c b/drivers/lightnvm/pblk-read.c
> >> index 54422a2..6a77c24 100644
> >> --- a/drivers/lightnvm/pblk-read.c
> >> +++ b/drivers/lightnvm/pblk-read.c
> >> @@ -475,7 +475,6 @@ int pblk_submit_read_gc(struct pblk *pblk, struct pblk_gc_rq *gc_rq)
> >>
> >>          if (pblk_submit_io_sync(pblk, &rqd)) {
> >>                  ret = -EIO;
> >> -               pblk_err(pblk, "GC read request failed\n");
> >>                  goto err_free_bio;
> >>          }
> >>
> >> diff --git a/drivers/lightnvm/pblk.h b/drivers/lightnvm/pblk.h
> >> index 5d1040a..52002f5 100644
> >> --- a/drivers/lightnvm/pblk.h
> >> +++ b/drivers/lightnvm/pblk.h
> >> @@ -427,6 +427,7 @@ struct pblk_smeta {
> >>
> >>   struct pblk_w_err_gc {
> >>          int has_write_err;
> >> +       int has_gc_err;
> >>          __le64 *lba_list;
> >>   };
> >>
> >> @@ -909,6 +910,7 @@ void pblk_gc_free_full_lines(struct pblk *pblk);
> >>   void pblk_gc_sysfs_state_show(struct pblk *pblk, int *gc_enabled,
> >>                                int *gc_active);
> >>   int pblk_gc_sysfs_force(struct pblk *pblk, int force);
> >> +void pblk_put_line_back(struct pblk *pblk, struct pblk_line *line);
> >>
> >>   /*
> >>    * pblk rate limiter
> >> --
> >> 2.9.5
> >>

  reply	other threads:[~2019-03-18 14:14 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-14 16:04 [PATCH 00/18] lightnvm: next set of improvements for 5.2 Igor Konopko
2019-03-14 16:04 ` [PATCH 01/18] lightnvm: pblk: fix warning in pblk_l2p_init() Igor Konopko
2019-03-16 22:29   ` Javier González
2019-03-18 16:25   ` Matias Bjørling
2019-03-14 16:04 ` [PATCH 02/18] lightnvm: pblk: warn when there are opened chunks Igor Konopko
2019-03-16 22:36   ` Javier González
2019-03-17 19:39   ` Matias Bjørling
2019-03-14 16:04 ` [PATCH 03/18] lightnvm: pblk: simplify partial read path Igor Konopko
2019-03-14 21:35   ` Heiner Litz
2019-03-15  9:52     ` Igor Konopko
2019-03-16 22:28       ` Javier González
2019-03-18 12:44         ` Igor Konopko
2019-03-14 16:04 ` [PATCH 04/18] lightnvm: pblk: OOB recovery for closed chunks fix Igor Konopko
2019-03-16 22:43   ` Javier González
2019-03-17 19:24     ` Matias Bjørling
2019-03-18 12:50       ` Igor Konopko
2019-03-18 19:25         ` Javier González
2019-03-14 16:04 ` [PATCH 05/18] lightnvm: pblk: propagate errors when reading meta Igor Konopko
2019-03-16 22:48   ` Javier González
2019-03-18 11:54   ` Hans Holmberg
2019-03-14 16:04 ` [PATCH 06/18] lightnvm: pblk: recover only written metadata Igor Konopko
2019-03-16 23:46   ` Javier González
2019-03-18 12:54     ` Igor Konopko
2019-03-18 15:04       ` Igor Konopko
2019-03-14 16:04 ` [PATCH 07/18] lightnvm: pblk: wait for inflight IOs in recovery Igor Konopko
2019-03-17 19:33   ` Matias Bjørling
2019-03-18 12:58     ` Igor Konopko
2019-03-14 16:04 ` [PATCH 08/18] lightnvm: pblk: fix spin_unlock order Igor Konopko
2019-03-16 23:49   ` Javier González
2019-03-18 11:55   ` Hans Holmberg
2019-03-14 16:04 ` [PATCH 09/18] lightnvm: pblk: kick writer on write recovery path Igor Konopko
2019-03-16 23:54   ` Javier González
2019-03-18 11:58   ` Hans Holmberg
2019-03-14 16:04 ` [PATCH 10/18] lightnvm: pblk: ensure that emeta is written Igor Konopko
2019-03-17 19:44   ` Matias Bjørling
2019-03-18 13:02     ` Igor Konopko
2019-03-18 18:26       ` Javier González
2019-03-21 13:34         ` Igor Konopko
2019-03-18  7:46   ` Javier González
2019-03-14 16:04 ` [PATCH 11/18] lightnvm: pblk: fix update line wp in OOB recovery Igor Konopko
2019-03-18  6:56   ` Javier González
2019-03-18 13:06     ` Igor Konopko
2019-03-14 16:04 ` [PATCH 12/18] lightnvm: pblk: do not read OOB from emeta region Igor Konopko
2019-03-17 19:56   ` Matias Bjørling
2019-03-18 13:05     ` Igor Konopko
2019-03-14 16:04 ` [PATCH 13/18] lightnvm: pblk: store multiple copies of smeta Igor Konopko
2019-03-18  7:33   ` Javier González
2019-03-18 13:12     ` Igor Konopko
2019-03-14 16:04 ` [PATCH 14/18] lightnvm: pblk: GC error handling Igor Konopko
2019-03-18  7:39   ` Javier González
2019-03-18 12:14   ` Hans Holmberg
2019-03-18 13:22     ` Igor Konopko
2019-03-18 14:14       ` Hans Holmberg [this message]
2019-03-14 16:04 ` [PATCH 15/18] lightnvm: pblk: fix in case of lack of lines Igor Konopko
2019-03-18  7:42   ` Javier González
2019-03-18 13:28     ` Igor Konopko
2019-03-18 19:21       ` Javier González
2019-03-21 13:21         ` Igor Konopko
2019-03-22 12:17           ` Hans Holmberg
2019-03-14 16:04 ` [PATCH 16/18] lightnvm: pblk: use nvm_rq_to_ppa_list() Igor Konopko
2019-03-18  7:48   ` Javier González
2019-03-14 16:04 ` [PATCH 17/18] lightnvm: allow to use full device path Igor Konopko
2019-03-18  7:49   ` Javier González
2019-03-18 10:28   ` Hans Holmberg
2019-03-18 13:18     ` Igor Konopko
2019-03-18 14:41       ` Hans Holmberg
2019-03-21 13:18         ` Igor Konopko
2019-03-25 11:40           ` Matias Bjørling
2019-03-14 16:04 ` [PATCH 18/18] lightnvm: track inflight target creations Igor Konopko

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=CANr-nt0CRVfWzJBDJD8P6zmC9VRPFDWKs-1Ueem64mN2cNFePA@mail.gmail.com \
    --to=hans@owltronix.com \
    --cc=hans.holmberg@cnexlabs.com \
    --cc=igor.j.konopko@intel.com \
    --cc=javier@javigon.com \
    --cc=linux-block@vger.kernel.org \
    --cc=mb@lightnvm.io \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).